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à.
# Scenari comuni per i ruoli IAM
Come per la maggior parte delle AWS funzionalità, in genere hai due modi per utilizzare un ruolo: in modo interattivo nella console IAM o a livello di codice con gli AWS CLI strumenti per Windows PowerShell o l'API.
+ Gli utenti IAM nell'account che utilizza la console IAM possono *passare* a un ruolo per utilizzare temporaneamente le autorizzazioni del ruolo nella console. Gli utenti abbandonano le loro autorizzazioni originali e assumono le autorizzazioni assegnate al ruolo. Quando gli utenti escono dal ruolo, le autorizzazioni originali vengono ripristinate.
+ Un'applicazione o un servizio offerto da AWS (come Amazon EC2) può *assumere* un ruolo richiedendo credenziali di sicurezza temporanee per un ruolo a cui effettuare richieste programmatiche. AWSÈ possibile utilizzare un ruolo in questo modo per non dover condividere o gestire le credenziali di sicurezza a lungo termine (ad esempio creando un utente IAM) per ogni entità che richiede l'accesso a una risorsa.
**Nota**
In questa guida le frasi *passare a un ruolo* e *assumere un ruolo* vengono utilizzate in modo intercambiabile.
Il modo più semplice per utilizzare i ruoli è quello di concedere agli utenti IAM le autorizzazioni per passare ai ruoli creati da te all'interno del tuo o di un altro Account AWS. È possibile passare da un ruolo all'altro facilmente utilizzando la console IAM per utilizzare le autorizzazioni che non si desidera abbiano normalmente e uscire dal ruolo per cedere a tali autorizzazioni. Ciò può aiutare a impedire l'accesso *accidentale* alle risorse sensibili o la loro modifica.
Per utilizzi più complessi di ruoli, ad esempio la concessione di accesso alle applicazioni e servizi, o gli utenti federati esterni, è possibile richiamare l'API `AssumeRole`. Questa chiamata API restituisce un set di credenziali temporanee che l'applicazione può utilizzare in successive chiamate API. Le operazioni tentate con le credenziali temporanee dispongono solo delle autorizzazioni concesse dal ruolo associato. Un'applicazione non deve "uscire" dal ruolo nello stesso modo di un utente nella console, ma l'applicazione smette semplicemente di utilizzare le credenziali temporanee e riprende le chiamate con le credenziali originali.
Gli utenti federati accedono utilizzando le credenziali di un provider di identità (IdP). AWS fornisce quindi credenziali temporanee all'IdP affidabile da trasmettere all'utente per includerle nelle AWS successive richieste di risorse. Queste credenziali forniscono le autorizzazioni concesse al ruolo assegnato.
Questa sezione fornisce una panoramica dei seguenti scenari:
+ [Fornisci l'accesso a un utente IAM in uno Account AWS di tua proprietà per accedere alle risorse di un altro account di tua proprietà](id_roles_common-scenarios_aws-accounts.md)
+ [Fornire l'accesso a carichi di lavoro non AWS](id_roles_common-scenarios_non-aws.md)
+ [Fornire l'accesso agli utenti IAM negli Account AWS di proprietà di terze parti](id_roles_common-scenarios_third-party.md)
+ [Fornisci l'accesso ai servizi offerti dalle AWSAWS risorse](id_roles_common-scenarios_services.md)
+ [Fornire l'accesso agli utenti autenticati esternamente (federazione delle identità)](id_roles_common-scenarios_federated-users.md)
# Accesso per un utente IAM in un altro Account AWS di tua proprietà
Puoi concedere ai tuoi utenti IAM il permesso di passare a ruoli interni a te Account AWS o a ruoli definiti in altri ruoli Account AWS di tua proprietà.
**Nota**
Se desideri concedere l'accesso a un account che non possiedi né controlli, consulta [Accesso a Account AWS siti di proprietà di terzi](id_roles_common-scenarios_third-party.md) più avanti in questo argomento.
Immaginiamo di avere delle istanze Amazon EC2 critiche per la tua organizzazione. Invece di concedere direttamente agli utenti l'autorizzazione a terminare le istanze, è possibile creare un ruolo con tali privilegi. Quindi consentire agli amministratori di passare al ruolo quando è necessario terminare un'istanza. In questo modo si aggiungono i seguenti livelli di protezione alle istanze:
+ È necessario concedere esplicitamente agli utenti il permesso di assumere quel ruolo.
+ I tuoi utenti devono passare attivamente al ruolo utilizzando Console di gestione AWS o assumere il ruolo utilizzando l' AWS API AWS CLI o.
+ È possibile aggiungere una Multi-Factor Authentication (MFA) al ruolo, in modo che solo gli utenti che accedono con un dispositivo MFA possano assumere quel ruolo. Per ulteriori informazioni su come configurare un ruolo in modo che gli utenti che assumono il ruolo debbano essere prima autenticati utilizzando l'autenticazione a più fattori (MFA), consulta [Accesso sicuro alle API con MFA](id_credentials_mfa_configure-api-require.md).
Consigliamo di utilizzare questo approccio per applicare il *principio di privilegio minimo*. Ciò significa limitare l'uso di autorizzazioni elevate unicamente a quelle volte in cui sono necessarie per operazioni specifiche. Per impedire le modifiche accidentali apportate agli ambienti sensibili, puoi utilizzare i ruoli, soprattutto se combinati con attività di [audit](cloudtrail-integration.md) per garantire che vengano utilizzati solo quando necessario.
Quando si crea un ruolo per questo scopo, è necessario specificare l'ID degli account da cui gli utenti devono accedere nell'elemento `Principal` della policy di affidabilità del ruolo. È quindi possibile concedere agli utenti specifici in tali altri account le autorizzazioni per passare al ruolo. 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).
Un utente in un account può passare a un ruolo dello stesso o di un altro account. Mentre si usa il ruolo, l'utente è in grado di eseguire solo le azioni e accedere solo alle risorse consentite dal ruolo; le loro autorizzazioni utente originali sono sospese. Quando l'utente esce dal ruolo, le autorizzazioni utente originali vengono ripristinate.
## Esempio di uno scenario in cui si utilizzano account di sviluppo e produzione separati
Immaginate che la vostra organizzazione disponga Account AWS di più elementi per isolare un ambiente di sviluppo da un ambiente di produzione. Gli utenti nell'account di sviluppo potrebbero occasionalmente aver bisogno di accedere alle risorse nell'account di produzione. Ad esempio, potrebbe essere necessario l'accesso a più account quando si sta richiedendo un aggiornamento dall'ambiente di sviluppo all'ambiente di produzione. Anche se è possibile creare identità separate (e password) per gli utenti che lavorano con entrambi gli account, la gestione delle credenziali per più account complica la gestione delle identità. Nell'illustrazione seguente, tutti gli utenti vengono gestiti nell'account di sviluppo, ma per alcuni sviluppatori è necessario un accesso limitato all'account di produzione. L'account di sviluppo dispone di due gruppi: collaudatori e sviluppatori, e ciascun gruppo ha la propria policy.
![\[Utilizzare un ruolo per delegare le autorizzazioni a un utente in un account diverso\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)
1. Nell'account di produzione, un amministratore utilizza IAM per creare il ruolo `UpdateApp` in tale account. Nel ruolo, l'amministratore definisce una policy di affidabilità che specifica l'account di sviluppo come `Principal`; in tal modo gli utenti autorizzati dall'account di sviluppo possono utilizzare il ruolo `UpdateApp`. L'amministratore definisce inoltre una policy delle autorizzazioni per il ruolo che specifica le autorizzazioni in lettura e scrittura per il bucket Amazon S3 denominato `productionapp`.
L'amministratore quindi condivide le informazioni appropriate con chiunque debba assumere quel ruolo. Tali informazioni sono il numero di account e il nome del ruolo (per gli utenti della AWS console) o l'Amazon Resource Name (ARN) (per AWS CLI l'accesso all' AWS API). L'ARN del ruolo può essere simile a `arn:aws:iam::123456789012:role/UpdateApp`, dove il ruolo è denominato `UpdateApp` ed è stato creato nel numero di account 123456789012.
**Nota**
L'amministratore può eventualmente configurare il ruolo in modo che gli utenti che assumono il ruolo debbano essere prima autenticati utilizzando l'autenticazione a più fattori (MFA). Per ulteriori informazioni, consulta [Accesso sicuro alle API con MFA](id_credentials_mfa_configure-api-require.md).
1. Nell'account di sviluppo, un amministratore concede ai membri del gruppo di sviluppatori l'autorizzazione a cambiare il ruolo. Ciò viene fatto concedendo al gruppo Developers l'autorizzazione a chiamare l'`AssumeRole`API AWS Security Token Service (AWS STS) per il `UpdateApp` ruolo. Qualsiasi utente IAM che appartiene al gruppo Sviluppatori nell'account di sviluppo può ora passare al ruolo `UpdateApp` nell'account di produzione. Gli altri utenti che non appartengono al gruppo di sviluppatori non hanno il permesso di passare al ruolo e pertanto non sono in grado di accedere al bucket S3 nell'account di produzione.
1. L'utente richiede di cambiare il ruolo:
+ AWS **console: l'utente sceglie il nome dell'account nella barra di navigazione e sceglie Switch Role.** L'utente specifica l'ID account (o alias) e il nome del ruolo. In alternativa, l'utente può fare clic su un collegamento inviato nell'e-mail dall'amministratore. Il link indirizza l'utente alla pagina **Switch Role (Cambia ruolo)** con i dettagli già compilati.
+ AWS API/AWS CLI: Un utente del gruppo Developers dell'account di sviluppo chiama la `AssumeRole` funzione per ottenere le credenziali per il ruolo. `UpdateApp` L'utente specifica l'ARN del ruolo `UpdateApp` come parte della chiamata. Se un utente nel gruppo di collaudatori inoltra la stessa richiesta, la richiesta ha esito negativo perché i collaudatori non hanno l'autorizzazione a chiamare `AssumeRole` per il `UpdateApp` ruolo ARN.
1. AWS STS restituisce credenziali temporanee:
+ AWS console: AWS STS verifica la richiesta con la politica di fiducia del ruolo per garantire che la richiesta provenga da un'entità attendibile (che è: l'account di sviluppo). Dopo la verifica, AWS STS restituisce [le credenziali di sicurezza temporanee](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) alla AWS console.
+ API/CLI: AWS STS verifica la richiesta rispetto alla politica di fiducia del ruolo per garantire che la richiesta provenga da un'entità attendibile (che è: l'account Development). Dopo la verifica, AWS STS restituisce le [credenziali di sicurezza temporanee](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) all'applicazione.
1. Le credenziali temporanee consentono l'accesso alla AWS risorsa:
+ AWS console: la AWS console utilizza le credenziali temporanee per conto dell'utente per tutte le azioni successive della console, in questo caso, per leggere e scrivere nel `productionapp` bucket. La console non è in grado di accedere ad altre risorse nell'account di produzione. Quando l'utente esce dal ruolo, le autorizzazioni dell'utente tornano a quelle originali detenute prima di cambiare il ruolo.
+ API/CLI: l'applicazione utilizza le credenziali di sicurezza provvisorie per aggiornare il bucket `productionapp`. Con le credenziali di sicurezza provvisorie, l'applicazione può solo leggere e scrivere al bucket `productionapp` e non è in grado di accedere a qualsiasi altra risorsa nell'account di produzione. L'applicazione non deve uscire dal ruolo, bensì cessa di utilizzare le credenziali provvisorie e utilizza le credenziali originali nelle successive chiamate API.
## Risorse aggiuntive
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Tutorial IAM: delega l'accesso tra AWS account utilizzando i ruoli IAM](tutorial_cross-account-with-roles.md)
# Accesso per AWS carichi non di lavoro
Un [ruolo IAM](id_roles.md) è un oggetto in AWS Identity and Access Management (IAM) a cui vengono assegnate le [autorizzazioni](access_policies.md). Quando [assumi quel ruolo](id_roles_manage-assume.md) utilizzando un'identità IAM o un'identità esterna a AWS, ti vengono fornite credenziali di sicurezza temporanee per la tua sessione di ruolo. Potresti avere carichi di lavoro in esecuzione nel tuo data center o in un'altra infrastruttura esterna AWS che deve accedere alle tue AWS risorse. Invece di creare, distribuire e gestire chiavi di accesso a lungo termine, puoi utilizzare AWS Identity and Access Management Roles Anywhere (IAM Roles Anywhere) per autenticare i tuoi carichi non di lavoro. AWS IAM Roles Anywhere utilizza i certificati X.509 dell'autorità di certificazione (CA) per autenticare le identità e fornire l'accesso in modo sicuro alle credenziali temporanee fornite da Servizi AWS un ruolo IAM.
**Per utilizzare IAM Roles Anywhere**
1. Configura una CA utilizzando [AWS Autorità di certificazione privata](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) o utilizza una CA dalla propria infrastruttura PKI.
1. Dopo aver impostato una CA, viene creato un oggetto in IAM Roles Anywhere chiamato *ancoraggio di fiducia*. Questo ancoraggio stabilisce la fiducia tra IAM Roles Anywhere e la tua CA per l'autenticazione.
1. Puoi quindi configurare i ruoli IAM esistenti o creare nuovi ruoli che si fidino del servizio IAM Roles Anywhere.
1. Autentica i tuoi AWS carichi non di lavoro con IAM Roles Anywhere utilizzando il trust anchor. AWS concede le credenziali temporanee non legate al AWS carico di lavoro al ruolo IAM che ha accesso alle tue risorse. AWS
## Risorse aggiuntive
Le risorse seguenti possono rivelarsi utili per fornire l'accesso a carichi di lavoro non AWS .
+ Per ulteriori informazioni sulla configurazione di Ruoli IAM Anywhere, consulta l'argomento [Cos'è AWS Identity and Access Management Ruoli Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) nella *Guida dell'utente di IAM Roles Anywhere*.
+ Per scoprire come configurare un'infrastruttura a chiave pubblica (PKI) per IAM Roles Anywhere, consulta [IAM Roles Anywhere con un'autorità di certificazione esterna](https://aws.amazon.com/blogs/) nel *Blog sulla sicurezza AWS *.
# Accesso a Account AWS siti di proprietà di terzi
Quando terze parti richiedono l'accesso alle AWS risorse dell'organizzazione, puoi utilizzare i ruoli per delegare l'accesso a tali risorse. Ad esempio, una terza parte potrebbe fornire un servizio per la gestione delle risorse AWS . Con i ruoli IAM, puoi concedere a queste terze parti l'accesso alle tue AWS risorse senza condividere le tue credenziali AWS di sicurezza. Invece, la terza parte può accedere alle tue AWS risorse assumendo un ruolo da te creato all'interno delle tue. Account AWS 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).
Le terze parti devono fornirti le informazioni seguenti per permetterti di creare un ruolo che possa essere da loro assunto:
+ **L' Account AWS ID della terza parte**. Puoi specificare il loro ID dell' Account AWS come entità principale quando definisci la policy di affidabilità per il ruolo.
+ **Un ID esterno da associare in modo univoco con il ruolo.** L'ID esterno può essere qualsiasi identificatore noto a te e alla terza parte. Puoi ad esempio usare un ID di fattura tra te e la terza parte, ma non devi usare qualcosa che sia possibile indovinare, ad esempio il nome o il numero di telefono della terza parte. Devi specificare questo ID quando definisci la policy di affidabilità per il ruolo. La terza parte deve fornire questo ID quando assume il ruolo.
+ **Le autorizzazioni di cui la terza parte necessita per usare le risorse AWS ** Devi specificare queste autorizzazioni quando definisci la policy di autorizzazione del ruolo. Questa policy definisce le operazioni consentite e le risorse a cui è possibile accedere.
Dopo aver creato il ruolo, devi fornire l'Amazon Resource Name (ARN) del ruolo alla terza parte. L'ARN del ruolo è necessario per assumere il ruolo.
**Importante**
Quando concedi a terze parti l'accesso alle tue AWS risorse, queste possono accedere a qualsiasi risorsa specificata nella politica. Le risorse usate dalla terza parte vengono fatturate a te. Assicurati di limitare l'uso delle risorse in modo appropriato.
## Esterno IDs per accesso da parte di terzi
Un ID esterno consente all'utente che sta assumendo il ruolo di dichiarare le circostanze in cui sta operando. Fornisce inoltre un modo per il proprietario dell'account di consentire che il ruolo venga assunto solo in circostanze specifiche. La funzione principale dell'ID esterno è quella di risolvere e prevenire il [Problema del "confused deputy"](confused-deputy.md).
**Importante**
AWS non considera l'ID esterno come segreto. Dopo aver creato un segreto, ad esempio una coppia di chiavi di accesso o una password AWS, non è possibile visualizzarli nuovamente. L'ID esterno di un ruolo può essere visualizzato da chiunque disponga dell'autorizzazione a visualizzarlo.
## Quando si deve usare l'ID esterno?
Utilizzare un ID esterno nelle seguenti situazioni:
+ Sei un Account AWS proprietario e hai configurato un ruolo per una terza parte che accede ad altri ruoli oltre Account AWS al tuo. È opportuno chiedere alla terza parte un ID esterno da includere quando assume il ruolo fornito alla terza parte. Quindi verificare l'ID esterno tramite la policy di affidabilità del ruolo fornito alla terza parte. Ciò garantisce che la parte esterna possa assumere il tuo ruolo solo quando agisce per conto del proprietario.
+ Ci si trova in una posizione che comporta l'assunzione di ruoli per conto di diversi clienti in modo analogo a Example Corp nello scenario precedente. È opportuno assegnare un ID esterno univoco a ciascun cliente e fornire indicazioni per aggiungere l'ID esterno alla policy di affidabilità creata per il ruolo da fornire. È quindi necessario assicurarsi di includere sempre l'ID esterno corretto nelle richieste di assunzione dei ruoli.
Probabilmente si dispone già di un identificativo univoco per ogni cliente e questo ID univoco è sufficiente per l'utilizzo come ID esterno. L'ID esterno non è un valore speciale da creare in modo esplicito o monitorare separatamente, solo per questo scopo.
Si deve sempre specificare l'ID esterno nelle chiamate API `AssumeRole`. Inoltre, quando un cliente assegna un ARN del ruolo, verificare se è possibile assumere il ruolo con e senza l'ID esterno corretto. Se è possibile assumere il ruolo senza l'ID esterno corretto, non memorizzare l'ARN del ruolo del cliente nel sistema. Attendere fino a quando il cliente non ha aggiornato la policy di affidabilità del ruolo per richiedere l'ID esterno corretto. In questo modo è possibile aiutare i clienti a operare nel modo corretto e pertanto a garantire la sicurezza di entrambi rispetto al problema "confused deputy".
## Scenario di esempio che utilizza un ID esterno
Ad esempio, supponiamo che tu decida di assumere una società terza chiamata Example Corp per monitorare Account AWS e ottimizzare i costi. Per tenere traccia delle spese giornaliere, Example Corp deve accedere alle tue AWS risorse. Example Corp controlla anche molti altri account AWS per altri clienti.
Non fornire l'accesso a Example Corp a un utente IAM e le relative credenziali a lungo termine nell'account AWS . Utilizza invece un ruolo IAM e le credenziali di sicurezza temporanee. Un ruolo IAM fornisce un meccanismo per consentire a terzi di accedere alle vostre AWS risorse senza dover condividere credenziali a lungo termine (come una chiave di accesso utente IAM).
Puoi utilizzare un ruolo IAM per stabilire una relazione di attendibilità tra il tuo Account AWS e l'account di Example Corp. Dopo aver stabilito questa relazione, un membro dell'account Example Corp può chiamare l' AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API per ottenere credenziali di sicurezza temporanee. I membri di Example Corp possono quindi utilizzare le credenziali per accedere alle AWS risorse del tuo account.
**Nota**
Per ulteriori informazioni sulle AssumeRole e altre operazioni AWS API che è possibile chiamare per ottenere credenziali di sicurezza temporanee, vedere. [Confronta le AWS STS credenziali](id_credentials_sts-comparison.md)
Di seguito è illustrata un'analisi più dettagliata di questo scenario.
1. L'Utente A affida un incarico a Example Corp, che crea un identificatore univoco per l'Utente A. Ti forniscono questo ID cliente univoco e il loro Account AWS numero. Queste informazioni sono necessarie per creare un ruolo IAM nella fase successiva.
**Nota**
Example Corp può utilizzare qualsiasi valore di stringa desiderato per il ExternalId, purché sia unico per ogni cliente. È possibile che si tratti di un numero di account cliente o addirittura di una stringa di caratteri casuale, purché non esistano due clienti con lo stesso valore. Non si tratta di un "segreto". Example Corp deve fornire il ExternalId valore a ciascun cliente. L'aspetto cruciale è che l'ID deve essere generato da Example Corp e ***non*** dai clienti affinché ogni ID esterno sia univoco.
1. Accedi AWS e crei un ruolo IAM che consente a Example Corp di accedere alle tue risorse. Come per qualsiasi ruolo IAM, il ruolo dispone di due tipi di policy: una policy di autorizzazione e una policy di attendibilità. La policy di affidabilità del ruolo specifica chi può assumere il ruolo. Nel nostro scenario di esempio, la policy specifica il Account AWS numero di Example Corp come. `Principal` Ciò consente alle identità di tale account di assumere il ruolo. Inoltre, viene aggiunto un elemento `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` alla policy di attendibilità. Questo elemento `Condition` verifica la chiave di contesto `ExternalId` per assicurarsi che corrisponda all'ID cliente univoco di Example Corp. Ad esempio:
```
"Principal": {"AWS": "Example Corp's Account AWS ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
```
1. La policy di autorizzazione per il ruolo specifica le operazioni che il ruolo consente di effettuare a un utente. Ad esempio, puoi specificare che il ruolo deve permettere agli utenti di gestire solo le risorse Amazon RDS e Amazon EC2, ma non gli utenti o i gruppi IAM. In questo scenario di esempio, si utilizza la policy di autorizzazione per fornire l'accesso in sola lettura per Example Corp a tutte le risorse nell'account dell'Utente A.
1. Dopo aver creato il ruolo, è necessario fornire l'Amazon Resource Name (ARN) del ruolo a Example Corp.
1. Quando Example Corp deve accedere alle tue AWS risorse, qualcuno dell'azienda chiama l'API. AWS `sts:AssumeRole` La chiamata include l'ARN del ruolo da assumere e il ExternalId parametro che corrisponde all'ID cliente.
Se la richiesta proviene da qualcuno che utilizza Example Corp e se l'ARN del ruolo e l'ID esterno sono corretti, la richiesta ha esito positivo. Account AWS Fornisce quindi credenziali di sicurezza temporanee che Example Corp può utilizzare per accedere alle AWS risorse consentite dal ruolo.
In altre parole, quando una policy di ruolo include un ID esterno, chiunque desideri assumere il ruolo deve essere un entità principale nel ruolo e deve includere l'ID esterno corretto.
## Punti chiave per l'esterno IDs
+ In un ambiente multi-tenant in cui si supportano più clienti con AWS account diversi, si consiglia di utilizzare un ID esterno per utente. Account AWS Questo ID dovrebbe essere una stringa casuale generata dalla terza parte.
+ Per richiedere che la terza parte fornisca un ID esterno quando si assume un ruolo, aggiorna la policy di attendibilità del ruolo con l'ID esterno scelto.
+ Per fornire un ID esterno quando assumi un ruolo, utilizza l' AWS API AWS CLI o per assumere quel ruolo. Per ulteriori informazioni, consulta l'operazione dell'[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API STS o l'operazione CLI STS [assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html).
+ Il valore `ExternalId` deve avere un minimo di 2 caratteri e un massimo di 1.224 caratteri. Il valore deve essere alfanumerico senza spazi. Può anche includere i seguenti simboli: più (\$1), uguale (=), virgola (,), punto (.), chiocciola (@), due punti (:), barra (/) e trattino (-).
## Risorse aggiuntive
Le risorse seguenti possono rivelarsi utili per fornire l'accesso a Account AWS di proprietà di terze parti.
+ Per informazioni su come consentire ad altri di eseguire azioni sul tuo computer, consulta. Account AWS[Creare un ruolo utilizzando policy di attendibilità personalizzate](id_roles_create_for-custom.md)
+ Per informazioni su come concedere l'autorizzazione per passare a un ruolo, consulta [Concedere le autorizzazioni agli utenti per cambiare ruoli](id_roles_use_permissions-to-switch.md)
+ Per informazioni su come creare e fornire a utenti attendibili credenziali di sicurezza temporanee, [Autorizzazioni per le credenziali di sicurezza temporanee](id_credentials_temp_control-access.md).
# Accesso a un AWS servizio
Molti AWS servizi richiedono l'utilizzo di ruoli per controllare a cosa può accedere il servizio. Un ruolo che un servizio assume per eseguire operazioni a tuo nome viene chiamato [ruolo del servizio](id_roles.md#iam-term-service-role). Quando un ruolo fornisce uno scopo specializzato per un servizio, questo può essere categorizzato come [ruolo collegato al servizio](id_roles.md#iam-term-service-linked-role). Consulta la [documentazione AWS](https://docs.aws.amazon.com/) di ciascun servizio per verificare se utilizza ruoli e per ulteriori informazioni su come assegnare un ruolo per il servizio da utilizzare.
Per informazioni dettagliate sulla creazione di un ruolo per delegare l'accesso a un servizio offerto da AWS, consulta[Creare un ruolo per delegare le autorizzazioni a un servizio AWS](id_roles_create_for-service.md).
# Accesso a utenti autenticati esternamente (federazione delle identità)
I tuoi utenti potrebbero già avere identità esterne AWS, ad esempio nella tua directory aziendale. Se tali utenti devono utilizzare AWS risorse (o utilizzare applicazioni che accedono a tali risorse), devono utilizzare anche credenziali AWS di sicurezza. È possibile utilizzare un ruolo IAM per specificare le autorizzazioni per gli utenti la cui identità è federata dalla propria organizzazione o da un provider di identità di terze parti (IdP).
**Nota**
Come best practice di sicurezza, ti consigliamo di gestire l'accesso degli utenti in [Centro identità IAM](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) con la federazione delle identità anziché creare utenti IAM. Per informazioni su situazioni specifiche in cui è richiesto un utente IAM, consulta la sezione [Quando creare un utente IAM invece di un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose).
## Federazione di utenti di una applicazione per dispositivi mobili o basata sul Web con Amazon Cognito
Se crei un'app mobile o basata sul Web che accede alle AWS risorse, l'app necessita di credenziali di sicurezza per poter effettuare richieste programmatiche a. AWS Per la maggior parte degli scenari relativi alle applicazioni per dispositivi mobili, consigliamo di utilizzare [Amazon Cognito](https://aws.amazon.com/cognito/). Puoi utilizzare questo servizio con [AWS Mobile SDK per iOS e Mobile SDK per](https://aws.amazon.com/sdkforios/) [Android e AWS Fire OS per creare identità uniche per gli utenti e](https://aws.amazon.com/sdkforandroid/) autenticarli per un accesso sicuro alle tue risorse. AWS Amazon Cognito supporta gli stessi provider di identità come quelli elencati nella sezione successiva e supporta anche [identità autenticate dallo sviluppatore](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities) e accesso non autenticato (ospite). Amazon Cognito fornisce inoltre operazioni API per la sincronizzazione dei dati utente in modo che vengano conservati quando gli utenti passano da un dispositivo all'altro. Per ulteriori informazioni, consulta [Amazon Cognito per applicazioni per dispositivi mobili](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito).
## Federazione degli utenti con provider di servizi di identità pubblica o OpenID Connect
Quando possibile, utilizza Amazon Cognito per scenari di applicazioni per dispositivi mobili o basate sul Web. Amazon Cognito si occupa della maggior parte del behind-the-scenes lavoro con i servizi di provider di identità pubblici per te. Lavora con gli stessi servizi di terze parti e supporta anche gli accessi anonimi. Tuttavia, per ulteriori scenari avanzati, è possibile lavorare direttamente con un servizio di terze parti, ad esempio Login with Amazon, Facebook, Google o qualsiasi IdP compatibile con OpenID Connect (OIDC). Per ulteriori informazioni sull'utilizzo della federazione OIDC utilizzando uno di questi servizi, consulta [Federazione OIDC](id_roles_providers_oidc.md).
## Federazione degli utenti con SAML 2.0
Se la tua organizzazione utilizza già un pacchetto software per provider di identità che supporta SAML 2.0 (Security Assertion Markup Language 2.0), puoi creare fiducia tra la tua organizzazione come provider di identità (IdP) e AWS come fornitore di servizi. Puoi quindi utilizzare SAML per fornire ai tuoi utenti il Single Sign-On federato (SSO) o l'accesso federato alle operazioni dell' Console di gestione AWS API di chiamata. AWS Ad esempio, se la tua azienda utilizza Microsoft Active Directory e Active Directory Federation Services, puoi effettuare la federazione utilizzando SAML 2.0. Per ulteriori informazioni sulla federazione degli utenti con SAML 2.0, consulta [Federazione SAML 2.0](id_roles_providers_saml.md).
## Federazione degli utenti creando un'applicazione personalizzata per la gestione di identità
Se il proprio archivio identità non è compatibile con SAML 2.0, è possibile creare un'applicazione personalizzata per la gestione di identità per eseguire una funzione simile. L'applicazione broker autentica gli utenti, richiede credenziali temporanee per gli utenti e quindi le fornisce all'utente per accedere alle AWS risorse. AWS
Ad esempio, Example Corp. ha molti dipendenti che devono eseguire applicazioni interne che accedono alle risorse dell'azienda. AWS I dipendenti hanno già identità nel sistema di identità e autenticazione dell'azienda ed Example Corp. non desidera creare un utente IAM separato per ogni dipendente dell'azienda.
Bob è uno sviluppatore presso Example Corp. Per consentire alle applicazioni interne di Example Corp. di accedere alle AWS risorse dell'azienda, Bob sviluppa un'applicazione di identity broker personalizzata. L'applicazione verifica che i dipendenti abbiano effettuato l'accesso nel sistema di identità e autenticazione esistente, che potrebbe utilizzare LDAP, Active Directory o un altro sistema. L'applicazione del gestore identità quindi ottiene le credenziali di sicurezza provvisorie per i dipendenti. Questo scenario è simile a quello precedente (un'app mobile che utilizza un sistema di autenticazione personalizzato), tranne per il fatto che le applicazioni che richiedono l'accesso alle AWS risorse vengono eseguite tutte all'interno della rete aziendale e l'azienda dispone di un sistema di autenticazione esistente.
Per ottenere le credenziali di sicurezza provvisorie, l'applicazione del gestore identità chiama `AssumeRole` o `GetFederationToken` per ottenere le credenziali di sicurezza provvisorie, a seconda di come Bob desidera gestire le policy per gli utenti e quando scadono le credenziali provvisorie. (Per ulteriori informazioni sulle differenze tra queste operazioni API, consultare [Credenziali di sicurezza temporanee in IAM](id_credentials_temp.md) e [Autorizzazioni per le credenziali di sicurezza temporanee](id_credentials_temp_control-access.md).) La chiamata restituisce credenziali di sicurezza temporanee costituite da un ID chiave di AWS accesso, una chiave di accesso segreta e un token di sessione. L'applicazione del gestore identità rende tali credenziali di sicurezza provvisorie disponibili all'applicazione aziendale interna. L'applicazione può quindi utilizzare le credenziali provvisorie per effettuare chiamate a AWS direttamente. L'app memorizza le credenziali finché non scadono e in seguito richiede un nuovo set di credenziali temporanee. L'immagine seguente illustra questo scenario.
![\[Esempio di flusso di lavoro in cui viene utilizzata un'applicazione personalizzata del gestore identità\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)
Questo scenario ha i seguenti attributi:
+ L'applicazione del gestore identità ha le autorizzazioni per accedere all'API di servizio token IAM (STS) per creare le credenziali di sicurezza temporanee.
+ L'applicazione del gestore identità è in grado di verificare che i dipendenti siano autenticati nel sistema di autenticazione esistente.
+ Gli utenti possono ottenere un URL temporaneo che consente loro di accedere alla Console di AWS gestione (denominata Single Sign-on).
Per ulteriori informazioni sulla creazione di credenziali di sicurezza provvisorie, consultare [Confronta le AWS STS credenziali](id_credentials_sts-comparison.md). Per ulteriori informazioni sull'accesso alla Console di gestione da parte dei principali federati SAML, consulta AWS . [Consentire ai principali federati SAML 2.0 di accedere a Console di gestione AWS](id_roles_providers_enable-console-saml.md)