Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Monitoraggio e controllo delle operazioni intraprese con i ruoli assunti Un [ruolo IAM](id_roles.md) è un oggetto in IAM a cui sono assegnate delle [autorizzazioni](access_policies.md). Quando [assumi quel ruolo](id_roles_manage-assume.md) utilizzando un'identità IAM o un'identità esterna AWS, ricevi una sessione con le autorizzazioni assegnate al ruolo. Quando esegui azioni in AWS, le informazioni sulla sessione possono essere registrate AWS CloudTrail per essere monitorate dall'amministratore dell'account. Gli amministratori possono configurare i ruoli in modo da richiedere alle identità di inviare una stringa personalizzata che identifichi la persona o l'applicazione che esegue operazioni in AWS. Queste informazioni di identità vengono archiviate come *identità di origine* in AWS CloudTrail. Quando l'amministratore esamina l'attività in CloudTrail, può visualizzare le informazioni sull'identità di origine per determinare chi o cosa ha eseguito le azioni nelle sessioni di ruolo assunte. Una volta impostata, l'identità di origine è presente nelle richieste di qualsiasi AWS azione intrapresa durante la sessione di ruolo. Il valore impostato persiste quando un ruolo viene utilizzato per assumere un altro ruolo tramite l' AWS API AWS CLI o, nota come [concatenamento dei ruoli](id_roles.md#iam-term-role-chaining). Il valore impostato non può essere modificato durante la sessione del ruolo. Gli amministratori possono configurare autorizzazioni granulari in base alla presenza o al valore dell'identità di origine per controllare ulteriormente AWS le azioni intraprese con ruoli condivisi. È possibile decidere se l'attributo dell'identità di origine può essere utilizzato, se è obbligatorio e quale valore può essere utilizzato. Il modo in cui si utilizza l'identità di origine differisce dal nome della sessione di ruolo e dai tag di sessione in modo importante. Il valore dell'identità di origine non può essere modificato dopo l'impostazione e persiste per eventuali operazioni aggiuntive eseguite con la sessione del ruolo. Ecco come utilizzare i tag di sessione e il nome della sessione del ruolo: + **Tag di sessione**: puoi passare i tag di sessione quando assumi un ruolo o federi un utente. I tag di sessione sono presenti quando si assume un ruolo. È possibile definire policy che utilizzano le chiavi condizionali sui tag per concedere autorizzazioni ai principali sulla base dei relativi tag. Quindi puoi utilizzarle CloudTrail per visualizzare le richieste fatte per assumere ruoli o federare gli utenti. Per ulteriori informazioni sui tag di sessione, consulta [Passa i tag di sessione AWS STS](id_session-tags.md). + **Nome sessione del ruolo**: puoi utilizzare la chiave di condizione `sts:RoleSessionName` in una policy di attendibilità del ruolo per richiedere che gli utenti forniscano un nome di sessione specifico quando assumono un ruolo. Il nome della sessione del ruolo può essere utilizzato per distinguere le sessioni del ruolo quando un ruolo viene utilizzato da principali diversi. Per saperne di più sul nome della sessione di ruolo, vedi [sts: RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname). Si consiglia di utilizzare l'identità di origine quando si desidera controllare l'identità che assume un ruolo. L'identità di origine è utile anche per CloudTrail i log di mining per determinare chi ha utilizzato il ruolo per eseguire azioni. **Topics** + [Configurazione per l'uso dell'identità di origine](#id_credentials_temp_control-access_monitor-setup) + [Cose da sapere sull'identità di origine](#id_credentials_temp_control-access_monitor-know) + [Autorizzazioni necessarie per impostare l'identità di origine](#id_credentials_temp_control-access_monitor-perms) + [Specifica di un'identità di origine quando si assume un ruolo](#id_credentials_temp_control-access_monitor-specify-sourceid) + [Utilizzo dell'identità di origine con AssumeRole](#id_credentials_temp_control-access_monitor-assume-role) + [Utilizzo dell'identità di origine con SAML AssumeRoleWith](#id_credentials_temp_control-access_monitor-assume-role-saml) + [Utilizzo dell'identità di origine con AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id) + [Controllo dell'accesso tramite le informazioni sull'identità di origine](#id_credentials_temp_control-access_monitor-control-access) + [Visualizzazione dell'identità di origine in CloudTrail](#id_credentials_temp_control-access_monitor-ct) ## Configurazione per l'uso dell'identità di origine Il modo in cui si imposta l'utilizzo dell'identità di origine dipende dal metodo utilizzato quando si assumono i ruoli. Ad esempio, gli utenti IAM potrebbero assumere ruoli direttamente utilizzando l'operazione `AssumeRole`. Se disponi di identità aziendali, note anche come identità della forza lavoro, queste potrebbero accedere alle tue risorse utilizzando. AWS `AssumeRoleWithSAML` Se gli utenti finali accedono alle tue applicazioni per dispositivi mobile o Web, potrebbero farlo utilizzando `AssumeRoleWithWebIdentity`. Di seguito è riportata una panoramica di alto livello del flusso di lavoro che consente di comprendere come impostare l'utilizzo delle informazioni sull'identità di origine nell'ambiente esistente. 1. **Configurazione di utenti e ruoli di test**: in un ambiente di preproduzione, configura utenti e ruoli di prova e configura le relative policy per consentire l'impostazione di un'identità di origine. Se utilizzi un provider di identità (IdP) per le identità federate, configura l'IdP per inviare un attributo utente a scelta per l'identità di origine nell'asserzione o nel token. 1. **Assunzione del ruolo**: verifica l'assunzione di ruoli e l'invio di un'identità di origine con gli utenti e i ruoli impostati per il test. 1. **Revisione CloudTrail**: rivedi le informazioni sull'identità di origine per i ruoli di test nei tuoi registri. CloudTrail 1. **Formazione degli utenti**: dopo aver eseguito il test nell'ambiente di preproduzione, assicurati che gli utenti sappiano come inviare le informazioni sull'identità di origine, se necessario. Imposta una scadenza per il momento in cui sarà richiesto agli utenti di fornire un'identità di origine nell'ambiente di produzione. 1. **Configurazione delle policy di produzione**: configura le policy per l'ambiente di produzione e quindi aggiungile agli utenti e ai ruoli di produzione. 1. **Monitora l'attività**: monitora l'attività del ruolo di produzione utilizzando i CloudTrail log. ## Cose da sapere sull'identità di origine Quando si utilizza un'identità di origine, tieni presente quanto segue. + Le policy di attendibilità per tutti i ruoli connessi a un provider di identità (IdP) devono disporre dell'autorizzazione `sts:SetSourceIdentity`. Per i ruoli che non dispongono di questa autorizzazione nella policy di attendibilità, l'operazione `AssumeRole*` avrà esito negativo. Se non desideri aggiornare la policy di attendibilità del ruolo per ogni ruolo, puoi utilizzare un'istanza IdP separata per passare l'identità di origine. Quindi, aggiungere l'autorizzazione `sts:SetSourceIdentity` solo ai ruoli connessi all'IdP separato. + Quando un'identità imposta un'identità di origine, la chiave `sts:SourceIdentity` è presente nella richiesta. Per le azioni successive intraprese durante la sessione di ruolo, la chiave `aws:SourceIdentity` è presente nella richiesta. AWS non controlla il valore dell'identità di origine nelle chiavi `sts:SourceIdentity` o `aws:SourceIdentity`. Se decidi di richiedere un'identità di origine, è necessario scegliere un attributo che sia fornito dagli utenti o dall'IdP. Per motivi di sicurezza, è necessario assicurarsi di poter controllare il modo in cui tali valori vengono forniti. + Il valore dell'identità di origine deve contenere tra 2 e 64 caratteri, può contenere solo caratteri alfanumerici, caratteri di sottolineatura e i seguenti caratteri: **. , \$1 = @ -** (trattino). Non è possibile utilizzare un valore che inizia con il testo **aws:**. Questo prefisso è riservato all'uso AWS interno. + Le informazioni sull'identità di origine non vengono acquisite CloudTrail quando un AWS servizio o un ruolo collegato al servizio esegue un'azione per conto di un'identità federata o della forza lavoro. **Importante** Non è possibile passare a un ruolo Console di gestione AWS che richiede l'impostazione di un'identità di origine al momento dell'assunzione del ruolo. Per assumere un ruolo di questo tipo, è possibile utilizzare l' AWS API AWS CLI or per richiamare l'`AssumeRole`operazione e specificare il parametro source identity. ## Autorizzazioni necessarie per impostare l'identità di origine Oltre a quella sull'operazione che corrisponde all'operazione API, è necessario disporre nella policy dell'autorizzazione per le seguenti operazioni: ``` sts:SetSourceIdentity ``` + Per specificare un'identità di origine, i principali (utenti e ruoli IAM) devono disporre delle autorizzazioni per`sts:SetSourceIdentity`. In qualità di amministratore, puoi configurarlo nella policy di attendibilità del ruolo e nella policy di autorizzazione del principale. + Quando si assume un ruolo con un altro ruolo, secondo la funzione denominata [concatenamento dei ruoli](id_roles.md#iam-term-role-chaining), le autorizzazioni per `sts:SetSourceIdentity` sono necessarie sia nella policy di autorizzazione del principale che assume il ruolo sia nella policy di attendibilità del ruolo del ruolo di destinazione. In caso contrario, l'operazione di assunzione del ruolo avrà esito negativo. + Quando si utilizza l'identità di origine, le policy di attendibilità dei ruoli per tutti i ruoli connessi a un provider di identità (IdP) devono disporre dell'autorizzazione `sts:SetSourceIdentity`. L'operazione `AssumeRole*` avrà esito negativo per qualsiasi ruolo connesso a un IdP senza questa autorizzazione. Se non desideri aggiornare la policy di attendibilità del ruolo per ogni ruolo, puoi utilizzare un'istanza IdP separata per inviare l'identità di origine e aggiungere l'autorizzazione `sts:SetSourceIdentity` solo ai ruoli connessi all'IdP separato. + Per impostare un'identità di origine oltre i limiti dell'account, è necessario includere l'autorizzazione `sts:SetSourceIdentity` in due posti. Deve trovarsi nella policy di autorizzazione del principale nell'account di origine e nella policy di attendibilità del ruolo del ruolo nell'account di destinazione. Questa operazione potrebbe essere necessaria, ad esempio, quando un ruolo viene utilizzato per assumere un ruolo in un altro account con il [concatenamento dei ruoli](id_roles.md#iam-term-role-chaining). Come amministratore dell'account, immagina di voler consentire all'utente IAM `DevUser` nel tuo account per assumere il `Developer_Role` nello stesso account. Tuttavia, si desidera consentire questa operazione solo se l'utente ha impostato l'identità di origine sul proprio nome utente IAM. La seguente policy può essere collegata a un utente IAM. **Example Esempio di politica basata sull'identità allegata a 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}" } } } ] } ``` Per applicare i valori di identità di origine accettabili, è possibile configurare la policy di attendibilità del ruolo riportata di seguito. La policy fornisce all'utente IAM le autorizzazioni `DevUser`per assumere il ruolo e impostare un'identità di origine. La chiave di condizione `sts:SourceIdentity` definisce il valore di identità di origine accettabile. **Example Esempio di policy di attendibilità dei ruoli dell'identità di origine** ------ #### [ 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" } } } ] } ``` ------ Utilizzando le credenziali per l'utente IAM`DevUser`, l'utente tenta di presumere l'`DeveloperRole`utilizzo della seguente richiesta. AWS CLI **Example Richiesta AssumeRole CLI di esempio** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/Developer_Role \ --role-session-name Dev-project \ --source-identity DevUser \ ``` Quando AWS valuta la richiesta, il contesto della richiesta contiene il `sts:SourceIdentity` comando di. `DevUser` ## Specifica di un'identità di origine quando si assume un ruolo È possibile specificare un'identità di origine quando si utilizza una delle operazioni AWS STS `AssumeRole*` API per ottenere credenziali di sicurezza temporanee per un ruolo. L'operazione API che usi è diversa a seconda del caso d'uso. Ad esempio, se utilizzi i ruoli IAM per consentire agli utenti IAM di accedere a AWS risorse a cui normalmente non hanno accesso, potresti utilizzare l'`AssumeRole`operazione. Se utilizzi la federazione delle identità aziendali per gestire gli utenti della forza lavoro, puoi utilizzare l'operazione `AssumeRoleWithSAML`. Se utilizzi la federazione OIDC per consentire agli utenti finali di accedere alle applicazioni mobili o Web, puoi utilizzare l'operazione `AssumeRoleWithWebIdentity`. Nelle sezioni seguenti viene illustrato come utilizzare l'identità di origine per ogni operazione. Per ulteriori informazioni sugli scenari comuni per le credenziali temporanee, consulta [Scenari comuni per le credenziali temporanee](id_credentials_temp.md#sts-introduction). ## Utilizzo dell'identità di origine con AssumeRole L'`AssumeRole`operazione restituisce un set di credenziali temporanee che è possibile utilizzare per accedere alle AWS risorse. È possibile utilizzare le credenziali dell'utente o del ruolo IAM per chiamare `AssumeRole`. Per passare l'identità di origine mentre assumi un ruolo, utilizzate l'`-–source-identity` AWS CLI opzione o il parametro `SourceIdentity` AWS API. L'esempio seguente illustra come specificare l'identità di origine utilizzando la AWS CLI. **Example Richiesta AssumeRole CLI di esempio** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/developer \ --role-session-name Audit \ --source-identity Admin \ ``` ## Utilizzo dell'identità di origine con SAML AssumeRoleWith Il principale che richiama l'operazione `AssumeRoleWithSAML` viene autenticato utilizzando la federazione basata su SAML. Questa operazione restituisce un set di credenziali temporanee che puoi utilizzare per accedere AWS alle risorse. Per ulteriori informazioni sull'utilizzo della federazione basata su SAML per Console di gestione AWS l'accesso, consulta. [Consentire ai principali federati SAML 2.0 di accedere a Console di gestione AWS](id_roles_providers_enable-console-saml.md) Per dettagli sull'accesso alle AWS CLI nostre AWS API, consulta. [Federazione SAML 2.0](id_roles_providers_saml.md) Per un tutorial sulla configurazione della federazione SAML per gli utenti di Active Directory, consulta [AWS Federated Authentication with Active Directory Federation Services (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) nel AWS Security Blog. In qualità di amministratore, puoi consentire ai membri della tua directory aziendale di unirsi AWS per utilizzare l'operazione. AWS STS `AssumeRoleWithSAML` A tale scopo, è necessario completare le seguenti attività: 1. [Configura un provider SAML nella tua organizzazione](id_roles_providers_saml_3rd-party.md). 1. [Creazione di un provider SAML in IAM](id_roles_providers_create_saml.md). 1. [Configura un ruolo e le relative autorizzazioni AWS per i tuoi responsabili federati SAML.](id_roles_create_for-idp_saml.md) 1. [Fine della configurazione del provider di identità SAML e creazione di asserzioni per la risposta di autenticazione SAML](id_roles_providers_create_saml_assertions.md) Per impostare un attributo SAML per l'identità di origine, includi l'elemento `Attribute` con l'attributo `Name` impostato su `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Utilizza l'elemento `AttributeValue` per specificare il valore dell'identità di origine. Ad esempio, si supponga di voler passare i seguenti attributi di identità come identità di origine: `SourceIdentity:DiegoRamirez` Per passare questi attributi, includi i seguenti elementi nell'asserzione SAML. **Example Esempio di frammento di un'asserzione SAML** ``` DiegoRamirez ``` ## Utilizzo dell'identità di origine con AssumeRoleWithWebIdentity Il principale che richiama l'operazione `AssumeRoleWithWebIdentity` viene autenticato utilizzando la federazione compatibile con OpenID Connect (OIDC). Questa operazione restituisce un insieme di credenziali temporanee che è possibile utilizzare per accedere alle risorse di AWS . Per ulteriori informazioni sull'utilizzo della federazione OIDC per l'accesso alla Console di gestione AWS , consulta [Federazione OIDC](id_roles_providers_oidc.md). Per passare l'identità di origine da OpenID Connect (OIDC), è necessario includere l'identità di origine nel Token Web JSON (JWT). Includi l’identità di origine nel namespace `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` nel token quando si invia la richiesta `AssumeRoleWithWebIdentity`. Per ulteriori informazioni sui token e le registrazioni OIDC, consultare [Utilizzo di token con pool di utenti](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) nella *Guida per gli sviluppatori Amazon Cognito *. Ad esempio, il seguente JWT decodificato è un token utilizzato per chiamare `AssumeRoleWithWebIdentity` con l'identità di origine `Admin`. **Example Esempio di token Web JSON decodificato** ``` { "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" } ``` ## Controllo dell'accesso tramite le informazioni sull'identità di origine Quando viene inizialmente impostata un'identità di origine, la SourceIdentity chiave [sts:](reference_policies_iam-condition-keys.md#ck_sourceidentity) è presente nella richiesta. Dopo aver impostato un'identità di origine, la SourceIdentity chiave [aws:](reference_policies_condition-keys.md#condition-keys-sourceidentity) è presente in tutte le richieste successive effettuate durante la sessione di ruolo. In qualità di amministratore, puoi scrivere politiche che concedano l'autorizzazione condizionale per eseguire AWS azioni in base all'esistenza o al valore dell'attributo di identità di origine. Immagina di voler richiedere ai tuoi sviluppatori di impostare un'identità di origine per assumere un ruolo fondamentale con il permesso di scrivere su una AWS risorsa fondamentale per la produzione. Immaginate inoltre di concedere AWS l'accesso alle identità della vostra forza lavoro utilizzando. `AssumeRoleWithSAML` Desideri solo che gli sviluppatori senior Saanvi e Diego abbiano accesso al ruolo, in modo che possano creare le seguenti policy di attendibilità per il ruolo. **Example Esempio di policy di attendibilità dei ruoli dell'identità di origine (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://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 policy di attendibilità contiene una condizione per `sts:SourceIdentity` che richiede un'identità di origine impostata su Saanvi o Diego per assumere il ruolo critico. In alternativa, se si utilizza un provider OIDC per la federazione e gli utenti sono autenticati con `AssumeRoleWithWebIdentity`, la tua policy di attendibilità del ruolo potrebbe avere un aspetto simile al seguente. **Example Esempio di policy di attendibilità dei ruoli dell'identità di origine (provider 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" ] } } } ] } ``` ------ ### Concatenamento dei ruoli e requisiti tra account Immagina di voler consentire agli utenti che hanno assunto il ruolo `CriticalRole` di assumere un ruolo `CriticalRole_2` in un altro account. Le credenziali della sessione del ruolo ottenute per assumere `CriticalRole` sono utilizzate per il [concatenamento dei ruoli](id_roles.md#iam-term-role-chaining) per un secondo ruolo, `CriticalRole_2`, in un account diverso. Il ruolo viene assunto oltre un limite di account. Pertanto, l'autorizzazione `sts:SetSourceIdentity` deve essere concessa in entrambe le policy di autorizzazione su `CriticalRole` e nella policy di attendibilità del ruolo su `CriticalRole_2`. **Example Esempio di politica di autorizzazione su CriticalRole** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2" } ] } ``` ------ Per proteggere l'impostazione dell'identità di origine attraverso il limite dell'account, la seguente policy di attendibilità del ruolo considera attendibile solo il principale del ruolo per `CriticalRole` per impostare l'identità di origine. **Example Esempio di politica di fiducia dei ruoli su \$12 CriticalRole** ------ #### [ 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'utente effettua la chiamata seguente utilizzando le credenziali della sessione di ruolo ottenute da assumendo. CriticalRole L'identità di origine è stata impostata durante l'assunzione di CriticalRole, quindi non è necessario impostarla nuovamente in modo esplicito. Se l'utente prova a impostare un'identità di origine diversa dal set di valori quando è stato assunto `CriticalRole`, la richiesta di assumere il ruolo verrà rifiutata. **Example Richiesta AssumeRole CLI di esempio** ``` aws sts assume-role \ --role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \ --role-session-name Audit \ ``` Quando il principale chiamante assume il ruolo, l'identità di origine nella richiesta persiste dalla prima sessione del ruolo assunto. Pertanto, entrambe le chiavi `aws:SourceIdentity` e `sts:SourceIdentity` sono presenti nel contesto della richiesta. ## Visualizzazione dell'identità di origine in CloudTrail È possibile utilizzare CloudTrail per visualizzare le richieste fatte per assumere ruoli o federare gli utenti. È inoltre possibile visualizzare le richieste di ruoli o utenti per eseguire operazioni in AWS. Il file di CloudTrail registro include informazioni sull'identità di origine impostata per il ruolo assunto o la sessione utente federata. Per ulteriori informazioni, consulta [Registrazione delle chiamate IAM e AWS STS API con AWS CloudTrail](cloudtrail-integration.md) Ad esempio, supponiamo che un utente effettui una AWS STS `AssumeRole` richiesta e imposti un'identità di origine. Puoi trovare le `sourceIdentity` informazioni nella `requestParameters` chiave del tuo CloudTrail registro. **Example Esempio di sezione RequestParameters in un registro AWS CloudTrail** ``` "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" } ``` Se l'utente utilizza la sessione di ruolo presunta per eseguire un'azione, le informazioni sull'identità di origine sono presenti nella `userIdentity` chiave del CloudTrail registro. **Example Esempio di chiave UserIdentity in un registro AWS CloudTrail** ``` { "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" } } } ``` Per vedere esempi di eventi AWS STS API nei CloudTrail log, consulta. [Esempi di eventi dell'API IAM nel registro CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api) Per maggiori dettagli sulle informazioni contenute nei file di CloudTrail registro, consulta [CloudTrail Event Reference](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) nella *Guida per l'AWS CloudTrail utente*.