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à.
# Tutorial IAM: delega l'accesso tra AWS account utilizzando i ruoli IAM
**Importante**
[Le migliori pratiche](best-practices.md) IAM consigliano di richiedere agli utenti umani di utilizzare la federazione con un provider di identità per accedere AWS utilizzando credenziali temporanee anziché utilizzare utenti IAM con credenziali a lungo termine. Ti consigliamo di utilizzare gli utenti IAM solo per [casi d'uso specifici](gs-identities-iam-users.md) non supportati dagli utenti federati.
In questo tutorial viene descritto come utilizzare un ruolo per delegare l'accesso a risorse che si trovano in diversi Account AWS di tua proprietà denominati **Destination** e **Originating**. Puoi condividere le risorse di un account con gli utenti di un altro account. Configurando in questo modo l'accesso fra account, non dovrai creare singoli utenti IAM per ogni account. Inoltre, gli utenti non devono uscire da un account e accedere a un altro per utilizzare risorse in Account AWS diversi. Dopo aver configurato il ruolo, vedrai come utilizzarlo tramite Console di gestione AWS AWS CLI, e l'API.
In questo tutorial, l'account **Destination** gestisce i dati delle applicazioni a cui accedono diverse applicazioni e team. In ciascun account puoi archiviare le informazioni sull'applicazione in bucket Amazon S3. Gestisci gli utenti IAM nell'account **Originating**, dove hai due ruoli utente IAM: **sviluppatori** e **analisti**. Gli sviluppatori e gli analisti utilizzano l'account **Originating** per generare dati condivisi da più microservizi. Entrambi i ruoli dispongono delle autorizzazioni per lavorare nell'account Originating e accedere alle sue risorse. Occasionalmente, uno sviluppatore deve aggiornare i dati condivisi nell'account **Destination**. Gli sviluppatori archiviano questi dati in un bucket Amazon S3 denominato `amzn-s3-demo-bucket-shared-container`.
Alla fine di questo tutorial, si dispone di quanto segue:
+ Utenti nell'account **Originating** (l'account attendibile) che possono assumere un ruolo specifico nell'account **Destination**.
+ Un ruolo nell'account **Destination** (l'account attendibile) che può accedere a uno specifico bucket Amazon S3.
+ Il bucket `amzn-s3-demo-bucket-shared-container` nell'account **Destination**.
Gli sviluppatori possono utilizzare il ruolo in Console di gestione AWS per accedere al `amzn-s3-demo-bucket-shared-container` bucket nell'account **Destination**. Inoltre, possono accedere al bucket utilizzando chiamate API autenticate tramite credenziali provvisorie fornite dal ruolo. La stessa operazione eseguita da un analista avrà esito negativo.
Questo flusso di lavoro ha tre fasi di base:
**[Creare un ruolo dell'account Destination](#tutorial_cross-account-with-roles-1)**
Innanzitutto, si utilizza il Console di gestione AWS per stabilire un rapporto di fiducia tra l'account di **destinazione** (numero ID 9999) e l'account di **origine** (numero ID 1111). Si inizia creando un ruolo IAM denominato. *UpdateData* Quando crei il ruolo, devi definire l'account **Originating** come entità attendibile e specificare una policy di autorizzazioni che consenta agli utenti attendibili di aggiornare il bucket `amzn-s3-demo-bucket-shared-container`.
**[Concedi autorizzazione per l'accesso al ruolo](#tutorial_cross-account-with-roles-2)**
In questa sezione, puoi modificare la policy del ruolo per negare l'accesso al ruolo `UpdateData` agli analisti. Perché gli analisti hanno PowerUser accesso in questo scenario e tu devi *negare* esplicitamente la possibilità di utilizzare il ruolo.
**[Accesso al test tramite cambio di ruoli](#tutorial_cross-account-with-roles-3)**
Infine, in qualità di sviluppatore utilizzerai il ruolo `UpdateData` per aggiornare il bucket `amzn-s3-demo-bucket-shared-container` nell'account **Destination**. Scopri come accedere al ruolo tramite la AWS console, l'e l' AWS CLI API.
## Considerazioni
Prima di utilizzare i ruoli IAM per delegare l'accesso alle risorse su più fronti Account AWS, è importante considerare quanto segue:
+ Non è possibile passare a un ruolo se l'accesso è stato effettuato come Utente root dell'account AWS.
+ I ruoli IAM e le policy basate sulle risorse delegano l'accesso tra account solo all'interno di una singola partizione. Ad esempio, si supponga di disporre di un account nella regione Stati Uniti occidentali (California settentrionale) nella partizione `aws` standard. Hai anche un account nella regione Cina (Pechino) nella partizione `aws-cn`. Non è possibile utilizzare una policy basata sulle risorse Amazon S3 nel tuo account nella regione Cina (Pechino) per consentire l'accesso agli utenti del tuo account `aws` standard.
+ Puoi utilizzarlo AWS IAM Identity Center per facilitare il Single Sign-On (SSO) per account esterni Account AWS (account esterni al tuo) utilizzando Security Assertion Markup Language (SAML AWS Organizations). Per i dettagli, consulta [Integrazione di sistemi esterni Account AWSAWS IAM Identity Center per la gestione centralizzata degli accessi](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en) con fatturazione indipendente tramite SAML 2.0
+ Puoi associare ruoli a AWS risorse come istanze o funzioni di Amazon EC2. AWS Lambda Per informazioni dettagliate, vedi [Creare un ruolo per delegare le autorizzazioni a un servizio AWS](id_roles_create_for-service.md).
+ Se desideri che un'applicazione assuma un ruolo in un'altra Account AWS, puoi utilizzare l' AWS SDK per l'assunzione di ruoli tra account. Per ulteriori informazioni, consulta [Autenticazione e accesso nella Guida](https://docs.aws.amazon.com//sdkref/latest/guide/access.html) di *riferimento agli strumenti AWS SDKs e agli strumenti.*
+ Il cambio di ruolo utilizzando il funziona Console di gestione AWS solo con account che non richiedono un`ExternalId`. Ad esempio, si supponga di concedere l'accesso al proprio account a terzi e di richiedere un `ExternalId` in un elemento `Condition` nella policy di autorizzazione. In tal caso, la terza parte può accedere all'account solo utilizzando l' AWS API o uno strumento da riga di comando. Le terze parti non possono utilizzare la console perché non sono in grado di fornire un valore per `ExternalId`. Per ulteriori informazioni su questo scenario[Accesso a Account AWS siti di proprietà di terzi](id_roles_common-scenarios_third-party.md), consulta e [Come abilitare l'accesso da più account a Console di gestione AWS nel](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) AWS Security Blog.
## Prerequisiti
Questo tutorial presuppone che tu abbia a disposizione quanto segue:
+ È possibile utilizzarne **due** Account AWS distinti, uno per rappresentare l'account di **origine** e uno per rappresentare l'account di **destinazione**.
+ Utenti e gruppi nell'account **Originating**, creati e configurati in questo modo:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ Non è necessario creare utenti nell'account **Destination**.
+ Un bucket Amazon S3 creato nell'account **Destination**. Nel tutorial puoi chiamarlo `amzn-s3-demo-bucket-shared-container`, ma dato che i nomi dei bucket S3 devono essere univoci a livello globale, dovrai selezionare un nome diverso.
## Creare un ruolo dell'account Destination
Puoi consentire agli utenti di uno di accedere Account AWS alle risorse di un altro Account AWS. In questo tutorial, ciò verrà effettuato creando un ruolo che definisca chi può accedervi e quali autorizzazioni concedere agli utenti che lo assumono.
In questo passaggio del tutorial, dovrai creare il ruolo nell'account **Destination** e impostare l'account **Originating** come entità attendibile. Inoltre, dovrai limitare le autorizzazioni del ruolo al solo accesso di lettura e scrittura per il bucket `amzn-s3-demo-bucket-shared-container`. Chiunque abbia ricevuto l'autorizzazione a usare il ruolo potrà leggere e scrivere nel bucket `shared-container`.
Prima di poter creare un ruolo, è necessario l'*ID dell'account* di **Originating** Account AWS. A ognuno Account AWS è assegnato un identificatore ID account univoco.
**Per ottenere l'ID di origine Account AWS**
1. Accedi Console di gestione AWS come amministratore dell'account **Originating** e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nella console IAM, scegli il tuo nome utente nella barra di navigazione in alto a destra. Di solito ha il seguente aspetto: ***username*@ *account\$1ID\$1number\$1or\$1alias***.
Per questo scenario, puoi utilizzare l'ID account 111111111111 per l'account **Originating**. Tuttavia, devi utilizzare un ID account valido se stai usando questo scenario nell'ambiente di test.
**Per creare un ruolo nell'account Destination che possa essere utilizzato dall'account Originating**
1. Accedi Console di gestione AWS come amministratore dell'account di **destinazione** e apri la console IAM.
1. Prima di creare il ruolo, prepara la policy gestita che definisce le autorizzazioni per i requisiti del ruolo. La policy verrà collegata al ruolo in una fase successiva.
Impostare l'accesso in lettura e scrittura al bucket `amzn-s3-demo-bucket-shared-container`. Sebbene AWS fornisca alcune policy gestite di Amazon S3, non ce n'è una che fornisca l'accesso in lettura e scrittura a un singolo bucket Amazon S3. Se lo desideri, puoi creare una policy personalizzata.
Nel pannello di navigazione, seleziona **Policy** e **Crea policy**.
1. Seleziona la scheda **JSON** e copia il testo dal documento della seguente policy JSON. Incollare il testo nella casella di testo **JSON**, sostituendo l'ARN della risorsa (`arn:aws:s3:::shared-container`) con quello per reale per il bucket Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
}
]
}
```
------
L'azione `ListAllMyBuckets` concede l'autorizzazione per elencare tutti i bucket di proprietà del mittente autenticato della richiesta. L'autorizzazione `ListBucket` consente agli utenti di visualizzare gli oggetti del bucket `amzn-s3-demo-bucket-shared-container`. Le autorizzazioni `GetObject`, `PutObject` e `DeleteObject` consentono agli utenti di visualizzare, aggiornare ed eliminare i contenuti del bucket `amzn-s3-demo-bucket-shared-container`.
**Nota**
È possibile alternare le opzioni dell'editor **Visivo** e **JSON** in qualsiasi momento. Se tuttavia si apportano modifiche o si seleziona **Successivo** nell'editor **Visivo**, IAM potrebbe ristrutturare la policy in modo da ottimizzarla per l'editor visivo. Per ulteriori informazioni, consulta [Modifica della struttura delle policy](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Nella pagina **Verifica policy**, digita **read-write-app-bucket** come nome della policy. Esamina le autorizzazioni concesse dalla policy, quindi scegli **Crea policy** per salvare il lavoro.
La nuova policy viene inserita nell'elenco delle policy gestite.
1. Nel riquadro di navigazione, scegli **Ruoli**, quindi **Crea ruolo**.
1. Scegli il tipo di ruolo **Un Account AWS**.
1. Per **ID account**, digita l'ID dell'account **Originating**.
Questo tutorial utilizza l'ID account di esempio **111111111111** per l'account di **Originating**. Tuttavia, è consigliabile utilizzare un ID account valido. Se utilizzi un ID account non valido, come ad esempio **111111111111**, IAM non ti consentirà di creare il nuovo ruolo.
Per il momento non è necessario richiedere un ID esterno, né chiedere agli utenti un'autenticazione a più fattori (MFA) per assumere il ruolo. Tali opzioni possono rimanere deselezionate. Per ulteriori informazioni, consulta [AWS Autenticazione a più fattori in IAM](id_credentials_mfa.md).
1. Selezionare **Next:Permissions (Avanti:Autorizzazioni)** per impostare le autorizzazioni associate al ruolo.
1. Seleziona la casella di controllo accanto alla policy creata in precedenza.
**Suggerimento**
In **Filter (Filtro)** selezionare **Customer managed (Gestite dal cliente)** per visualizzare solo le policy create. Il filtro nasconde le policy create da AWS per semplificare la ricerca.
Quindi, seleziona **Successivo**.
1. (Facoltativo) Aggiungi metadati al ruolo collegando i tag come coppie chiave-valore. Per ulteriori informazioni sull'utilizzo dei tag in IAM, consultare [Tag per AWS Identity and Access Management le risorse](id_tags.md).
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per il nuovo ruolo.
1. Dopo avere rivisto il ruolo, fare clic su **Create Role (Crea ruolo)**.
Il ruolo `UpdateData` viene visualizzato nell'elenco dei ruoli.
A questo punto, è necessario ottenere l'Amazon Resource Name (ARN), un identificatore univoco per il ruolo. Quando modifichi il ruolo dello sviluppatore nell'account Originating, specifica l'ARN del ruolo dell'account Destination per concedere o negare le autorizzazioni.
**Per ottenere l'ARN per UpdateData**
1. Nel pannello di navigazione della console IAM seleziona **Ruoli**.
1. Nell'elenco dei ruoli, selezionare il ruolo `UpdateData`.
1. Nella sezione **Summary (Riepilogo)** del riquadro dei dettagli, copiare il valore **Role ARN (ARN ruolo)**.
L'ID dell'account Destination è 999999999999, pertanto l'ARN del ruolo sarà `arn:aws:iam::999999999999:role/UpdateData`. Assicurati di fornire l' Account AWS ID reale dell'account di destinazione.
A questo punto, hai stabilito un rapporto di fiducia tra gli account **Destination** e **Originating**. È stato possibile creando un ruolo nell'account **Destination** che identifica l'account **Originating** come principale attendibile. Inoltre, hai definito le operazioni consentite agli utenti che passano al ruolo `UpdateData`.
Quindi, modifica le autorizzazioni per il ruolo da sviluppatore.
## Concedi autorizzazione per l'accesso al ruolo
A questo punto, sia gli analisti che gli sviluppatori dispongono delle autorizzazioni che consentono di gestire i dati dell'account **Originating**. Usare i seguenti passaggi necessari per aggiungere le autorizzazioni per il cambio di ruolo.
**Modificare il ruolo Sviluppatori per consentire loro di passare al UpdateData ruolo**
1. Accedi come amministratore nell'account **Originating** e apri la console IAM.
1. Seleziona **Ruoli** e quindi **Developers**.
1. Nella scheda **Autorizzazioni**, scegli **Aggiungi autorizzazioni**, quindi **Crea policy in linea**.
1. Scegli la scheda **JSON**.
1. Aggiungi la seguente istruzione di policy per consentire l'azione `AssumeRole` sul ruolo `UpdateData` nell'account Destination. Assicurati di modificare *DESTINATION-ACCOUNT-ID* l'`Resource`elemento con l' Account AWS ID effettivo dell'account di destinazione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
L'effetto `Allow` consente in modo esplicito al gruppo Sviluppatori l'accesso al ruolo `UpdateData` dell'account Destination. Qualsiasi sviluppatore potrà accedere al ruolo.
1. Scegliere **Esamina policy**.
1. Digita un **nome**, ad esempio **allow-assume-S3-role-in-destination**.
1. Scegli **Crea policy**.
Nella maggior parte degli ambienti, la procedura seguente risulta superflua. Se, tuttavia, utilizzi PowerUserAccess le autorizzazioni, alcuni gruppi potrebbero già essere in grado di cambiare ruolo. La procedura descritta di seguito mostra come aggiungere un'autorizzazione `"Deny"` al gruppo Analisti, per impedire ai suoi membri di assumere il ruolo. Se questa procedura non è necessaria nel tuo ambiente, è preferibile non aggiungerla. Le autorizzazioni `"Deny"` di tipo generale sono più complicate da gestire e comprendere. Utilizza le autorizzazioni `"Deny"` solo quando non sono disponibili alternative migliori.
**Per modificare il ruolo Analisti e negare l'autorizzazione ad assumere tale ruolo `UpdateData`**
1. Scegli **Ruoli**, quindi scegli **Analisti**.
1. Nella scheda **Autorizzazioni**, scegli **Aggiungi autorizzazioni**, quindi **Crea policy in linea**.
1. Scegli la scheda **JSON**.
1. Aggiungere la seguente istruzione di policy per negare l'operazione `AssumeRole` nel ruolo `UpdateData`. Assicurati di modificare *DESTINATION-ACCOUNT-ID* l'`Resource`elemento con l' Account AWS ID effettivo dell'account di destinazione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
L'effetto `Deny` impedisce in modo esplicito al gruppo Analisi l'accesso al ruolo `UpdateData` dell'account Destination. Se un analista prova ad accedere al ruolo riceve un messaggio di accesso negato.
1. Scegliere **Esamina policy**.
1. Digita un **nome** come **deny-assume-S3-role-in-destination**.
1. Scegli **Crea policy**.
Il gruppo Sviluppatori ora dispone delle autorizzazioni per utilizzare il ruolo `UpdateData` nell'account Destination. Il ruolo Analista invece non può utilizzare il ruolo `UpdateData`.
Successivamente, vedrai come David, uno sviluppatore, può accedere al bucket `amzn-s3-demo-bucket-shared-container` nell'account Destination. David può accedere al bucket dalla Console di gestione AWS AWS CLI, dalla o dall' AWS API.
## Accesso al test tramite cambio di ruoli
Al termine dei primi due passaggi del tutorial, disponi di un ruolo che concede l'accesso a una risorsa dell'account **Destination**. Hai anche creato un ruolo nell'account **Originating** con utenti autorizzati a utilizzare tale ruolo. In questo passaggio viene illustrato come testare il passaggio a quel ruolo tramite Console di gestione AWS AWS CLI, l'e l' AWS API.
Per ottenere assistenza su problemi comuni che possono verificarsi durante l'utilizzo dei ruoli IAM, consulta [Risoluzione dei problemi relativi ai ruoli IAM](troubleshoot_roles.md).
### Cambio di ruoli (Console)
Se David deve aggiornare i dati nell'account **Destination** in Console di gestione AWS, può farlo utilizzando **Switch Role**. Specificando l'ID account o l'alias e il nome del ruolo, le sue autorizzazioni passano immediatamente a quelle consentite dal ruolo. Potrà quindi utilizzare la console per lavorare con il bucket `amzn-s3-demo-bucket-shared-container`, ma non sarà in grado utilizzare le altre risorse dell'account **Destination**. Inoltre, mentre utilizza il ruolo, David non può sfruttare i suoi privilegi di utente avanzato, validi per l'account **Originating**, perché non si possono attivare più set di autorizzazioni contemporaneamente.
IAM fornisce due alternative per accedere alla pagina **Switch Role (Cambia ruolo)**:
+ David riceve dal suo amministratore un link che rimanda a una configurazione "Switch Role" (Cambia ruolo) predefinita. Il collegamento viene fornito all'amministratore nella pagina finale della procedura guidata **Create role (Crea ruolo)** oppure nella pagina **Role Summary (Riepilogo ruolo)** per un ruolo tra più account. Selezionando questo link, David viene indirizzato alla pagina **Switch Role (Cambia ruolo)** con i campi **Account ID (ID account)** e **Role name (Nome ruolo)** già compilati. David non deve fare altro che selezionare **Cambia ruoli**.
+ Anziché spedire un'e-mail con il link, l'amministratore invia il numero **Account ID (ID account)** e i valori per **Role Name (Nome ruolo)**. Per cambiare ruolo, David deveinserire manualmente i valori. Tale procedura viene descritta di seguito.
**Come assumere un ruolo**
1. David accede Console di gestione AWS utilizzando il suo utente normale nell'account **Originating**.
1. Seleziona il link che l'amministratore gli ha inviato per e-mail. A questo punto, David viene indirizzato alla pagina **Switch Role** (Cambia ruolo) che contiene già le informazioni relative all'ID account o all'alias e il nome del ruolo.
oppure
David seleziona il proprio nome nel menu Identity (Identità) della barra di navigazione, quindi sceglie **Switch Roles** (Cambia ruolo).
Se questa è la prima volta che David cerca di accedere alla pagina Switch Role (Cambia ruolo) in questo modo, verrà visualizzata una pagina introduttiva di **Switch Role (Cambia ruolo)** In questa pagina sono riportate ulteriori informazioni su come il cambio di ruolo può consentire agli utenti di gestire le risorse su più Account AWS. In questa pagina, David deve selezionare **Switch Role (Cambia ruolo)** per completare il resto della procedura.
1. Successivamente, per accedere al ruolo, David dovrà digitare manualmente il numero di ID dell'account Destination (`999999999999`) e il nome del ruolo (`UpdateData`).
Inoltre, David vuole monitorare quali ruoli e autorizzazioni associate sono attualmente attivi su IAM. Per tenere traccia di queste informazioni, digita `Destination` nella casella di testo **Nome di visualizzazione**, seleziona l'opzione di colore rosso e quindi seleziona **Cambia ruolo**.
1. Ora David può utilizzare la console Amazon S3 per lavorare con il bucket Amazon S3 o con qualsiasi altra risorsa per la quale il ruolo `UpdateData` dispone di autorizzazioni.
1. Al termine, David può tornare alle sue autorizzazioni originali. A tale scopo, seleziona il nome del ruolo **Destination** nella barra di navigazione, quindi seleziona **Torna a David @ 111111111111**.
1. Se dovesse avere nuovamente bisogno di cambiare ruolo, David potrà selezionare il menu **Identità** nel riquadro di navigazione e troverà già presente la voce Destination. Non dovrà fare altro che selezionare tale voce per cambiare immediatamente ruolo, senza immettere nuovamente l'account ID e il nome del ruolo.
### Cambio di ruoli (AWS CLI)
Se David dovesse avere bisogno di lavorare nell'ambiente **Destination**, alla riga di comando, può farlo tramite la [AWS CLI](https://aws.amazon.com/cli/). Esegue il comando `aws sts assume-role` e trasferisce l'ARN del ruolo per ottenere le credenziali di sicurezza provvisorie per quel ruolo. Quindi configura tali credenziali nelle variabili di ambiente in modo che AWS CLI i comandi successivi funzionino utilizzando le autorizzazioni del ruolo. Mentre utilizza il ruolo, David non può sfruttare i suoi privilegi di utente avanzato, validi per l'account **Originating**, perché non si possono attivare più set di autorizzazioni contemporaneamente.
Tutte le chiavi di accesso e i token sono solo esempi e non possono essere utilizzati come mostrato. Sostituiscili con i valori appropriati del tuo ambiente reale.
**Come assumere un ruolo**
1. David apre una finestra del prompt dei comandi e conferma che il AWS CLI client funziona eseguendo il comando:
```
aws help
```
**Nota**
L'ambiente predefinito di David utilizza le credenziali utente `David` ottenute dal profilo predefinito creato con il comando `aws configure`. Per ulteriori informazioni, consulta [Configurazione della AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) nella *Guida per l'utente di AWS Command Line Interface *.
1. Inizia il processo di cambio ruolo eseguendo il seguente comando per passare al ruolo `UpdateData` dell'account **Destination**. Ha ricevuto l'ARN del ruolo dall'amministratore che ha creato il ruolo. Il comando richiede anche un nome di sessione (qualsiasi testo è valido).
```
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"
```
A questo punto David potrà consultare quanto segue:
```
{
"Credentials": {
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
"Expiration": "2014-12-11T23:08:07Z",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
}
}
```
1. David può trovare le tre parti di cui ha bisogno nella sezione Credentials (Credenziali) dell'output.
+ `AccessKeyId`
+ `SecretAccessKey`
+ `SessionToken`
David deve configurare l' AWS CLI ambiente per utilizzare questi parametri nelle chiamate successive. Per informazioni sui vari modi di configurare le credenziali, consulta [Configurare AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence). Non può utilizzare il comando `aws configure`, perché non supporta l'acquisizione il token della sessione. Tuttavia, può inserire manualmente le informazioni in un file di configurazione. Poiché si tratta di credenziali provvisorie, con una durata relativamente breve, è più facile per aggiungerle all'ambiente della sessione corrente della riga di comando.
1. Per aggiungere i tre valori all'ambiente, David taglia e incolla l'output del passaggio precedente nei comandi seguenti. Per risolvere i problemi con gli accapo presenti nel token della sessione, è possibile tagliare e incollare in un semplice editor di testo. Il testo deve essere inserito come un'unica stringa lunga, anche se qui viene riportato spezzato, per motivi di chiarezza.
L'esempio seguente mostra i comandi forniti nell'ambiente Windows, dove "set" è il comando per creare una variabile di ambiente. Su un computer Linux o MacOS, bisogna utilizzare invece il comando "export". Tutte le altre parti dell'esempio sono valide per tutti i tre ambienti.
Per dettagli sull'utilizzo di Tools for Windows Powershell, consulta [Passare a un ruolo IAM (Tools for Windows PowerShell)](id_roles_use_switch-role-twp.md)
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
DHq6ikBQ==
```
A questo punto, tutti i comandi successivi vengono eseguiti con le autorizzazioni del ruolo identificato da tali credenziali (nel caso di David, il ruolo `UpdateData`).
**Importante**
Puoi salvare le impostazioni di configurazione e le credenziali utilizzate di frequente nei file gestiti da AWS CLI. Per ulteriori informazioni, consulta [File di configurazione e delle credenziali esistenti](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing) nella *Guida per l'utente di AWS Command Line Interface *.
1. Eseguire il comando per accedere alle risorse dell'account Destination. In questo esempio, David si limita a elencare il contenuto del suo bucket S3 con il comando seguente.
```
aws s3 ls s3://shared-container
```
Poiché i nomi del bucket Amazon S3 sono universalmente univoci, non è necessario specificare quale ID account possiede il bucket. Per accedere alle risorse di altri AWS servizi, consulta la AWS CLI documentazione del servizio per conoscere i comandi e la sintassi necessari per fare riferimento alle relative risorse.
### Utilizzo di AssumeRole (AWS API)
Per aggiornare l'account **Destination** da codice, David effettua una chiamata `AssumeRole` per assumere il ruolo `UpdateData`. La chiamata restituisce le credenziali provvisorie, utilizzabili per accedere al bucket `amzn-s3-demo-bucket-shared-container` dell'account **Destination**. David può utilizzare tali credenziali per effettuare chiamate API per aggiornare il bucket `amzn-s3-demo-bucket-shared-container`. Tuttavia, non sarà in grado di effettuare chiamate API per accedere alle altre risorse dell'account **Destination**, anche se dispone di autorizzazioni da utente avanzato per l'account **Originating**.
**Come assumere un ruolo**
1. David richiama `AssumeRole` come parte di un'applicazione Deve specificare l'ARN di `UpdateData`: `arn:aws:iam::999999999999:role/UpdateData`.
La risposta alla chiamata `AssumeRole` include le credenziali temporanee con un `AccessKeyId` e un `SecretAccessKey`. Include anche un'ora `Expiration` che indica quando le credenziali scadono e sarà necessario richiederne di nuove. Quando configuri il concatenamento dei ruoli con l' AWS SDK, molti provider di credenziali aggiornano automaticamente le credenziali prima che scadano.
1. David utilizza le credenziali provvisorie per inviare una chiamata `s3:PutObject` per aggiornare il bucket `amzn-s3-demo-bucket-shared-container`. Trasferisce le credenziali alla chiamata API come parametro `AuthParams`. Dato che le credenziali provvisorie del ruolo forniscono solo un accesso in lettura e scrittura al bucket `amzn-s3-demo-bucket-shared-container`, tutte le altre azioni nell'account Destination sono negate.
Per un esempio di codice (con Python), consultare [Passa a un ruolo IAM (AWS API)](id_roles_use_switch-role-api.md).
## Risorse aggiuntive
Le seguenti risorse possono aiutarti a saperne di più sugli argomenti trattati in questo tutorial:
+ Per ulteriori informazioni sugli utenti IAM, consulta [Identità IAM](id.md).
+ Per ulteriori informazioni sui bucket Amazon S3, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
+ Per capire se i principali negli account esterni alla zona di attendibilità (organizzazione o account attendibile) dispongono dell'accesso per assumere i ruoli, consulta [Cos'è IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
## Riepilogo
Hai completato il tutorial per l'accesso alle API di più account. Hai creato un ruolo per stabilire la relazione di trust con un altro account e hai definito le operazioni che possono essere eseguite dalle entità affidabili. Successivamente, hai modificato una policy del ruolo per controllare quali utenti IAM possono accedere al ruolo. Come risultato, gli sviluppatori dell'account **Originating** possono aggiornare il bucket `amzn-s3-demo-bucket-shared-container` dell'account **Destination**, utilizzando credenziali provvisorie.