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à.
# Creazione di ruoli IAM
Per creare un ruolo, puoi utilizzare l' Console di gestione AWS AWS CLI API Tools for Windows PowerShell o IAM.
Se utilizzi il Console di gestione AWS, una procedura guidata ti guida attraverso i passaggi per la creazione di un ruolo. La procedura guidata prevede passaggi leggermente diversi a seconda che tu stia creando un ruolo per un AWS servizio, per un o per un principale Account AWS federato SAML o OIDC.
**Ruoli per gli utenti IAM**
Crea questo ruolo per delegare le autorizzazioni all'interno del tuo ruolo Account AWS o a ruoli definiti in altri ruoli di tua proprietà. Account AWS 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.
Per ulteriori informazioni, consulta [Creazione di un ruolo per fornire le autorizzazioni a un utente IAM](id_roles_create_for-user.md).
Per ulteriori informazioni sulla creazione di ruoli per l'accesso multi-account, consulta [Creare un ruolo utilizzando policy di attendibilità personalizzate](id_roles_create_for-custom.md).
**Ruoli per i servizi AWS**
Creare questo ruolo per delegare le autorizzazioni per un servizio che può eseguire operazioni per tuo conto Un [ruolo di servizio](id_roles.md#iam-term-service-role) che passi a un servizio deve avere una policy IAM con le autorizzazioni che consentano al servizio di eseguire azioni associate a quel servizio. Sono necessarie autorizzazioni diverse per ciascuno dei servizi AWS .
Per ulteriori informazioni sulla creazione dei ruoli di servizio, consulta [Creare un ruolo per delegare le autorizzazioni a un servizio AWS](id_roles_create_for-service.md).
Per ulteriori informazioni sulla creazione di ruoli collegati al servizio, consulta [Creare un ruolo collegato ai servizi](id_roles_create-service-linked-role.md).
**Ruoli per la federazione delle identità**
Crea questo ruolo per delegare le autorizzazioni agli utenti che hanno già identità esterne a AWS. Quando utilizzi un provider di identità, non devi creare un codice di accesso personalizzato né gestire le tue identità utente. I tuoi utenti esterni accedono tramite un IdP e puoi concedere a tali identità esterne le autorizzazioni per utilizzare le AWS risorse del tuo account. I provider di identità aiutano a proteggere l' AWS account perché non è necessario distribuire o incorporare credenziali di sicurezza a lungo termine, come le chiavi di accesso, nell'applicazione.
Per ulteriori informazioni, consulta [Creazione di un ruolo per un provider di identità di terze parti](id_roles_create_for-idp.md).
# Creazione di un ruolo per fornire le autorizzazioni a un utente IAM
Puoi utilizzare i ruoli IAM per fornire l'accesso alle tue AWS risorse. Con i ruoli IAM, puoi stabilire relazioni di fiducia tra il tuo account *fiduciario* e altri account AWS *affidabili*. L'account che concede fiducia possiede la risorsa alla quale accedere e l'account affidabile contiene gli utenti che devono accedere alla risorsa. Tuttavia, è possibile che un altro account sia proprietario di una risorsa nell'account in uso. L'account che concede fiducia potrebbe infatti consentire all'account attendibile di creare nuove risorse, ad esempio creando nuovi oggetti in un bucket Amazon S3. In tal caso, l'account che crea la risorsa ne è proprietario e controlla chi può accedervi.
Dopo aver creato la relazione di fiducia, un utente IAM o un'applicazione dell'account affidabile può utilizzare l'operazione [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API AWS Security Token Service (AWS STS). Questa operazione fornisce credenziali di sicurezza temporanee che consentono l'accesso alle AWS risorse del tuo account.
Gli account possono essere controllati da sé stessi oppure l'account con gli utenti può essere controllato da terze parti. Se l'altro account con gli utenti è un account Account AWS che non controlli, puoi utilizzare l'`externalId`attributo. L'ID esterno può essere qualsiasi parola o numero concordato tra l'utente e l'amministratore dell'account di terze parti. Questa opzione aggiunge automaticamente una condizione alla policy di affidabilità che consente all'utente di assumere il ruolo solo se la richiesta include il corretto `sts:ExternalID`. Per ulteriori informazioni, consulta [Accesso a Account AWS siti di proprietà di terzi](id_roles_common-scenarios_third-party.md).
Per informazioni su come utilizzare i ruoli per delegare le autorizzazioni, consultare [Termini e concetti dei ruoli](id_roles.md#id_roles_terms-and-concepts). Per informazioni sull'utilizzo di un ruolo di servizio per consentire l'accesso a risorse nel proprio account, consultare [Creare un ruolo per delegare le autorizzazioni a un servizio AWS](id_roles_create_for-service.md).
## Creazione di un ruolo IAM (console)
Puoi utilizzare il Console di gestione AWS per creare un ruolo che un utente IAM può assumere. Ad esempio, supponiamo che l'organizzazione disponga di più Account AWS elementi per isolare un ambiente di sviluppo da un ambiente di produzione. Per informazioni di alto livello sulla creazione di un ruolo che consenta agli utenti nell'account di sviluppo di accedere alle risorse nell'account di produzione, consulta la sezione [Esempio di uno scenario in cui si utilizzano account di sviluppo e produzione separati](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example).
**Autorizzazioni minime**
Per eseguire le seguenti operazioni, devi disporre come minimo delle seguenti autorizzazioni IAM:
`access-analyzer:ValidatePolicy`
`iam:AttachRolePolicy`
`iam:CreatePolicy`
`iam:CreateRole`
`iam:GetAccountSummary`
`iam:GetPolicy`
`iam:GetPolicyVersion`
`iam:GetRole`
`iam:ListAccountAliases`
`iam:ListAttachedRolePolicies`
`iam:ListOpenIDConnectProviders`
`iam:ListPolicies`
`iam:ListRolePolicies`
`iam:ListRoles`
`iam:ListRoleTags`
`iam:ListSAMLProviders`
------
#### [ Console ]
1. Accedi a Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel riquadro di navigazione della console, selezionare **Ruoli** e **Crea ruolo**.
1. Scegli il tipo di ruolo **Account AWS**.
1. Per creare un ruolo per il tuo account, scegli **This account** (Questo account). Per creare un ruolo per un altro account, scegli **Altro Account AWS** e inserisci l'**ID account ID** al quale desideri concedere l'accesso alle risorse.
L'amministratore dell'account specificato può concedere l'autorizzazione di assumere questo ruolo a qualsiasi utente IAM in tale account. Per eseguire questa operazione, l'amministratore collega una policy all'utente o al gruppo che garantisce l'autorizzazione per l'operazione `sts:AssumeRole`. Tale policy deve specificare il nome ARN del ruolo `Resource`.
1. Per concedere le autorizzazioni agli utenti da un account di cui non hai il controllo e se tali utenti assumeranno il ruolo a livello di programmazione, seleziona **Require external ID** (Richiedi ID esterno). L'ID esterno può essere qualsiasi parola o numero concordato tra l'utente e l'amministratore dell'account di terze parti. Questa opzione aggiunge automaticamente una condizione alla policy di affidabilità che consente all'utente di assumere il ruolo solo se la richiesta include il corretto `sts:ExternalID`. Per ulteriori informazioni, consulta [Accesso a Account AWS siti di proprietà di terzi](id_roles_common-scenarios_third-party.md).
**Importante**
La scelta di questa opzione limita l'accesso al ruolo solo tramite Tools for Windows PowerShell o l' AWS API. AWS CLI Questo perché non è possibile utilizzare la AWS console per passare a un ruolo che presenta una `externalId` condizione nella politica di attendibilità. Tuttavia, è possibile creare questo tipo di accesso a livello di codice scrivendo uno script o un'applicazione utilizzando il kit SDK rilevante. Per ulteriori informazioni e uno script di esempio, consulta [Come abilitare l'accesso tra account alla Console di gestione AWS](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) nel Blog sulla sicurezza di AWS .
1. Se si desidera limitare il ruolo agli utenti che accedono con la multi-factor authentication (MFA), selezionare **Require MFA (Richiedi MFA)**. Questa opzione aggiunge una condizione alla policy di affidabilità del ruolo che controlla un accesso MFA. Un utente che desidera assumere il ruolo deve accedere con una password monouso temporanea da un dispositivo MFA configurato. Gli utenti senza autenticazione MFA non possono assumere il ruolo. Per ulteriori informazioni sulla funzionalità MFA, consultare [AWS Autenticazione a più fattori in IAM](id_credentials_mfa.md).
1. Scegli **Next (Successivo)**.
1. IAM include un elenco delle politiche AWS gestite e gestite dai clienti nel tuo account. Selezionare la policy delle autorizzazioni da utilizzare o scegliere **Crea policy** per aprire una nuova scheda del browser e creare una nuova policy da zero. Per ulteriori informazioni, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start). Una volta creata la policy, chiudere la scheda e tornare alla scheda originale. Selezionare la casella di controllo accanto alle policy di autorizzazione da assegnare a chiunque assuma il ruolo. È anche possibile non selezionare le policy ora e collegarle al ruolo in un secondo momento. Per default, un ruolo non dispone di autorizzazioni.
1. (Facoltativo) Impostare un [limite delle autorizzazioni](access_policies_boundaries.md). Questa è una caratteristica avanzata.
Aprire la sezione **Set permissions boundary (Imposta limite delle autorizzazioni)** e selezionare **Use a permissions boundary to control the maximum role permissions (Usa un limite delle autorizzazioni per controllare il numero massimo di autorizzazioni del ruolo)**. Selezionare la policy da utilizzare per il limite delle autorizzazioni.
1. Scegli **Next (Successivo)**.
1. In **Nome ruolo**, immetti un nome per il ruolo. I nomi dei ruoli devono essere univoci all'interno del tuo Account AWS. Quando il nome di un ruolo viene utilizzato in una policy o come parte di un ARN, il nome del ruolo fa distinzione tra maiuscole e minuscole. Quando un nome di ruolo viene visualizzato ai clienti nella console, ad esempio durante la procedura di accesso, il nome del ruolo non fa distinzione tra maiuscole e minuscole. Poiché varie entità possono fare riferimento al ruolo, non puoi modificare il nome del ruolo dopo averlo creato.
1. (Facoltativo) In **Description** (Descrizione), inserisci una descrizione per il nuovo ruolo.
1. Scegli **Edit** (Modifica) nelle sezioni **Step 1: Select trusted entities** (Fase 1: seleziona le entità attendibili) o **Step 2: Add permissions** (Fase 2: aggiungi autorizzazioni) per modificare i casi d'uso e le autorizzazioni per il ruolo. Verrai reindirizzato alle pagine precedenti per apportare le modifiche.
1. (Facoltativo) Aggiungere 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. Rivedere il ruolo e scegliere **Crea ruolo**.
**Importante**
Ricordare che questa è solo la prima metà della configurazione obbligatoria. È inoltre necessario fornire ai singoli utenti nell'account attendibile l'autorizzazione a passare al ruolo nella console o ad assumere il ruolo a livello di codice. Per ulteriori informazioni su questa fase, consultare [Concedere le autorizzazioni agli utenti per cambiare ruoli](id_roles_use_permissions-to-switch.md).
------
## Creazione di un ruolo IAM (AWS CLI)
La creazione di un ruolo da a AWS CLI comporta più passaggi. Quando si utilizza la console per creare un ruolo, molti passaggi vengono eseguiti automaticamente, ma con la console è AWS CLI necessario eseguire ogni passaggio in modo esplicito e autonomo. È necessario creare il ruolo e quindi assegnargli una policy di autorizzazione. Puoi anche scegliere di impostare il [limite delle autorizzazioni](access_policies_boundaries.md) per il ruolo.
**Per creare un ruolo per accesso tra account (AWS CLI)**
1. Creare un ruolo: [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)
1. [Allega una politica di autorizzazioni gestite al ruolo: aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)
or
[Crea una politica di autorizzazioni in linea per il ruolo: aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
1. (Facoltativo) Aggiungere attributi personalizzati al ruolo collegando tag: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
Per ulteriori informazioni, consulta [Gestione dei tag sui ruoli (AWS CLI o AWS API) IAM](id_tags_roles.md#id_tags_roles_procs-cli-api).
1. [(Facoltativo) Imposta il [limite delle autorizzazioni](access_policies_boundaries.md) per il ruolo: aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)
Il limite delle autorizzazioni controlla il numero massimo di autorizzazioni che è possibile concedere a un ruolo. I limiti delle autorizzazioni sono una funzionalità avanzata. AWS
L'esempio seguente mostra i primi due passaggi, più comuni, per la creazione di un ruolo per più account in un ambiente semplice. Questo esempio permette agli utenti dell'account `123456789012` di assumere il ruolo e visualizzare il bucket `example_bucket` di Amazon S3. L'esempio presuppone inoltre l'uso un computer client con Windows e che l'interfaccia a riga di comando sia già configurata con le credenziali dell'account e la regione. Per ulteriori informazioni, vedere [Configurazione dell'interfaccia a AWS riga di comando](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).
In questo esempio, è necessario includere la seguente policy di attendibilità nel primo comando al momento della creazione del ruolo. Questa policy di attendibilità consente agli utenti dell'account `123456789012` di assumere il ruolo tramite l'operazione `AssumeRole`, ma solo se l'utente fornisce l'autenticazione MFA utilizzando i parametri `SerialNumber` e `TokenCode`. Per ulteriori informazioni sulla funzionalità MFA, consultare [AWS Autenticazione a più fattori in IAM](id_credentials_mfa.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole",
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
}
]
}
```
------
**Importante**
Se l'elemento `Principal` contiene l'ARN per un determinato utente o ruolo IAM, quando la policy viene salvata l'ARN viene trasformato in un ID principale univoco. Ciò aiuta a mitigare il rischio che qualcuno aumenti le proprie autorizzazioni rimuovendo e ricreando il ruolo o l'utente. Questo ID non è normalmente presente nella console, perché avviene anche una trasformazione inversa nell'ARN quando la policy di affidabilità viene visualizzata. Tuttavia, se si elimina il ruolo o l'utente, l'ID principale viene visualizzato nella console perché non è più AWS possibile mapparlo su un ARN. Pertanto, se si elimina e crea nuovamente un utente o un ruolo a cui viene fatto riferimento in un elemento `Principal` della policy di attendibilità, è necessario modificare il ruolo per sostituire l'ARN.
Quando si utilizza il secondo comando, è necessario collegare una policy gestita esistente al ruolo. La policy delle autorizzazioni seguente consente agli utenti che assumono il ruolo di eseguire solo l'operazione `ListBucket` sul bucket `example_bucket` di Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
]
}
```
------
Per creare questo ruolo `Test-UserAccess-Role`, è prima necessario salvare la policy di attendibilità precedente con il nome `trustpolicyforacct123456789012.json` nella cartella `policies` dell'unità `C:` locale. Quindi salva la precedente politica di autorizzazione come politica gestita dai clienti nel tuo account Account AWS con il nome. `PolicyForRole` È quindi possibile utilizzare i comandi seguenti per creare il ruolo e collegare la policy gestita.
```
# Create the role and attach the trust policy file that allows users in the specified account to assume the role.
$ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json
# Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do.
$ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole
```
**Importante**
Ricordare che questa è solo la prima metà della configurazione obbligatoria. È inoltre necessario fornire a singoli utenti nell'account affidabile le autorizzazioni per passare al ruolo. Per ulteriori informazioni su questa fase, consultare [Concedere le autorizzazioni agli utenti per cambiare ruoli](id_roles_use_permissions-to-switch.md).
Dopo aver creato il ruolo e avergli concesso le autorizzazioni per eseguire AWS attività o accedere alle AWS risorse, qualsiasi utente dell'`123456789012`account può assumere il ruolo. Per ulteriori informazioni, consulta [Passaggio a un ruolo IAM (AWS CLI)](id_roles_use_switch-role-cli.md).
## Creazione di un ruolo IAM (AWS API)
La creazione di un ruolo dall' AWS API prevede diversi passaggi. Quando si usa la console per creare un ruolo, molti dei passaggi vengono eseguiti automaticamente, ma con l'API ogni passaggio deve essere eseguito esplicitamente dall'utente. È necessario creare il ruolo e quindi assegnargli una policy di autorizzazione. Puoi anche scegliere di impostare il [limite delle autorizzazioni](access_policies_boundaries.md) per il ruolo.
**Creare un ruolo nel codice (AWS API)**
1. Crea un ruolo: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
Per la policy di affidabilità del ruolo, è possibile specificare una posizione del file.
1. Allega una politica di autorizzazione gestita al ruolo: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
or
Crea una politica di autorizzazione in linea per il ruolo: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
**Importante**
Ricordare che questa è solo la prima metà della configurazione obbligatoria. È inoltre necessario fornire a singoli utenti nell'account affidabile le autorizzazioni per passare al ruolo. Per ulteriori informazioni su questa fase, consultare [Concedere le autorizzazioni agli utenti per cambiare ruoli](id_roles_use_permissions-to-switch.md).
1. (Facoltativo) Aggiungi attributi personalizzati all'utente allegando tag: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
Per ulteriori informazioni, consulta [Gestione dei tag sugli utenti IAM (AWS CLI o AWS API)](id_tags_users.md#id_tags_users_procs-cli-api).
1. (Facoltativo) Imposta il [limite delle autorizzazioni per il ruolo](access_policies_boundaries.md): [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)
Il limite delle autorizzazioni controlla il numero massimo di autorizzazioni che è possibile concedere a un ruolo. I limiti delle autorizzazioni sono una funzionalità avanzata. AWS
Dopo aver creato il ruolo e avergli concesso le autorizzazioni per eseguire AWS attività o accedere alle AWS risorse, è necessario concedere le autorizzazioni agli utenti dell'account per consentire loro di assumere il ruolo. Per ulteriori informazioni sull'assunzione di un ruolo, consulta [Passa a un ruolo IAM (AWS API)](id_roles_use_switch-role-api.md).
## Creazione di un ruolo IAM (AWS CloudFormation)
Per informazioni sulla creazione di un ruolo IAM in AWS CloudFormation, consulta il [riferimento alle risorse e alle proprietà e](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html) [gli esempi nella Guida](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples) per l'*AWS CloudFormation utente*.
Per ulteriori informazioni sui modelli IAM in AWS CloudFormation, consulta gli [snippet di AWS Identity and Access Management modello nella Guida](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html) per l'*AWS CloudFormation utente*.
# Creare un ruolo per delegare le autorizzazioni a un servizio AWS
Molti AWS servizi richiedono l'utilizzo di ruoli per consentire al servizio di accedere alle risorse di altri servizi per conto dell'utente. 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). Per visualizzare i servizi che supportano ruoli collegati ai servizi, oppure se un servizio supporta qualsiasi forma di credenziali provvisorie, consulta [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md). Per apprendere come un singolo servizio utilizza i ruoli, scegli il nome del servizio nella tabella e visualizza la documentazione relativa a tale servizio.
Quando imposti l'autorizzazione `PassRole`, devi assicurarti che un utente non invii un ruolo dove il ruolo dispone di più autorizzazioni di quelle che desideri che l'utente abbia. Ad esempio, Alice potrebbe non essere autorizzata a eseguire alcune operazioni su Amazon S3. Se Alice potesse trasferire un ruolo a un servizio che consente le azioni di Amazon S3, il servizio potrebbe eseguire azioni Amazon S3 per conto di Alice durante l'esecuzione del processo.
Per informazioni su come i ruoli aiutano a delegare le autorizzazioni, consulta [Termini e concetti dei ruoli](id_roles.md#id_roles_terms-and-concepts).
## Autorizzazioni del ruolo del servizio
Per consentire a una entità IAM (utente o ruolo) di creare o modificare un ruolo di servizio, occorre configurare le autorizzazioni.
**Nota**
L'ARN per un ruolo collegato ai servizi include un principale del servizio, indicata nelle policy seguenti come `SERVICE-NAME.amazonaws.com`. Non tentare di indovinare il principale del servizio, perché fa distinzione tra maiuscole e minuscole e il formato può variare tra i servizi AWS . Per visualizzare l'entità principale di un servizio, consulta la relativa documentazione del ruolo collegato al servizio.
**Come consentire a un'entità IAM di creare un ruolo di servizio specifico**
Aggiungi la policy seguente all'entità IAM che deve creare il ruolo di servizio. Questa policy ti permette di creare un ruolo del servizio per il servizio specificato e utilizzando un nome specifico. Puoi quindi collegare le policy gestite o inline a tale ruolo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
]
}
```
------
**Come consentire a un'entità IAM di creare un qualsiasi ruolo di servizio**
AWS consiglia di consentire solo agli utenti amministrativi di creare qualsiasi ruolo di servizio. Una persona con autorizzazioni per creare un ruolo e allegare qualsiasi policy può eseguire l'escalation delle proprie autorizzazioni. Invece, crea una policy che consenta a questa persona di creare solo i ruoli di cui hanno bisogno o lascia che un amministratore crei il ruolo di servizio per suo conto.
Per allegare una policy che consenta a un amministratore di accedere all'intero account Account AWS, utilizza la policy [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS gestita.
**Come consentire a un'entità IAM di modificare un ruolo di servizio**
Aggiungi la policy seguente all'entità IAM che deve modificare il ruolo di servizio.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EditSpecificServiceRole",
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:PutRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
},
{
"Sid": "ViewRolesAndPolicies",
"Effect": "Allow",
"Action": [
"iam:GetPolicy",
"iam:ListRoles"
],
"Resource": "*"
}
]
}
```
------
**Come consentire a un'entità IAM di eliminare un ruolo di servizio specifico**
Aggiungi l'istruzione seguente alla policy delle autorizzazioni per l'entità IAM che deve eliminare il ruolo di servizio specificato.
```
{
"Effect": "Allow",
"Action": "iam:DeleteRole",
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
```
**Come consentire a un'entità IAM di eliminare qualunque ruolo di servizio**
AWS consiglia di consentire solo agli utenti amministrativi di eliminare qualsiasi ruolo di servizio. Invece, crea una policy che consenta loro di eliminare solo i ruoli di cui hanno bisogno o lascia che un amministratore elimini il ruolo di servizio per suo conto.
Per allegare una politica che consenta a un amministratore di accedere all'intero account Account AWS, utilizza la politica [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS gestita.
## Creazione di un ruolo per un AWS servizio (console)
È possibile utilizzare il Console di gestione AWS per creare un ruolo per un servizio. Dal momento che alcuni servizi supportano più ruoli del servizio, consulta la [documentazione AWS](https://docs.aws.amazon.com/) relativa al servizio per determinare quale caso d'uso selezionare. È possibile apprendere come assegnare le necessarie policy di affidabilità e autorizzazioni al ruolo, in modo che il servizio possa assumere quel ruolo per conto dell'utente. Le operazioni che è possibile utilizzare per controllare le autorizzazioni per il tuo ruolo possono variare, a seconda del modo in cui il servizio definisce i casi d'uso e della creazione o meno di un ruolo collegato ai servizi.
------
#### [ Console ]
**Per creare un ruolo per una Servizio AWS (console IAM)**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel pannello di navigazione della console IAM, scegliere **Ruoli** e quindi **Crea ruolo**.
1. Per **Tipo di entità attendibile**, seleziona **Servizio AWS**.
1. Per **Servizio o caso d'uso**, scegli un servizio, quindi scegli il caso d'uso. I casi d'uso sono definiti dal servizio per includere la policy di fiducia richiesta dal servizio.
1. Scegli **Next (Successivo)**.
1. Per **Policy di autorizzazione**, le opzioni dipendono dal caso d'uso selezionato:
+ Se il servizio definisce le autorizzazioni per il ruolo, le policy di autorizzazioni non possono essere selezionate.
+ Seleziona una policy da un set limitato di policy di autorizzazione.
+ Seleziona una policy tra tutte le policy di autorizzazione.
+ Non selezionare policy di autorizzazioni, crea le policy dopo la creazione del ruolo e quindi collegale al ruolo.
1. (Facoltativo) Impostare un [limite delle autorizzazioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html). Questa è una funzionalità avanzata disponibile per i ruoli di servizio, ma non per i ruoli collegati ai servizi.
1. Apri la sezione **Imposta limite delle autorizzazioni** e seleziona **Usa un limite delle autorizzazioni per controllare il numero massimo di autorizzazioni del ruolo**.
IAM include un elenco delle politiche AWS gestite e gestite dal cliente nel tuo account.
1. Selezionare la policy da utilizzare per il limite delle autorizzazioni.
1. Scegli **Next (Successivo)**.
1. Per **Nome del ruolo**, le opzioni dipendono dal servizio:
+ Se il servizio definisce il nome del ruolo, non puoi modificarlo.
+ Se il servizio definisce un prefisso per il nome del ruolo, puoi inserire un suffisso facoltativo.
+ Se il servizio non definisce il nome del ruolo, puoi assegnare un nome al ruolo.
**Importante**
Quando assegni un nome a un ruolo, tieni presente quanto segue:
I nomi dei ruoli devono essere univoci all'interno del tuo Account AWS account e non possono essere resi unici per caso.
Ad esempio, non creare ruoli denominati **PRODROLE** e **prodrole**. Quando il nome di un ruolo viene utilizzato in una policy o come parte di un ARN, il nome del ruolo fa distinzione tra maiuscole e minuscole, tuttavia quando un nome di ruolo viene visualizzato ai clienti nella console, ad esempio durante il processo di accesso, il nome del ruolo non fa distinzione tra maiuscole e minuscole.
Non è possibile modificare il nome del ruolo dopo averlo creato, in quanto altre entità possono fare riferimento al ruolo.
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per il ruolo.
1. (Facoltativo) Per modificare i casi d'uso e le autorizzazioni per il ruolo, in **Fase 1: seleziona le entità attendibili** o **Fase 2: aggiungi autorizzazioni** seleziona **Modifica**.
1. (Facoltativo) Per facilitare l'identificazione, l'organizzazione o la ricerca del ruolo, aggiungi i tag come coppie chiave-valore. Per ulteriori informazioni sull'utilizzo dei tag in IAM, consulta [Tags for AWS Identity and Access Management resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *IAM User Guide*.
1. Verificare il ruolo e quindi scegliere **Create role (Crea ruolo)**.
------
## Creazione di un ruolo per un servizio (AWS CLI)
La creazione di un ruolo da AWS CLI richiede diversi passaggi. Quando usi la console per creare un ruolo, molti passaggi vengono eseguiti automaticamente, ma con la AWS CLI devi eseguire esplicitamente ogni passaggio da solo. È necessario creare il ruolo e quindi assegnargli una policy di autorizzazione. Se il servizio in uso è Amazon EC2, è necessario creare anche un profilo dell'istanza e aggiungervi il ruolo. Puoi anche scegliere di impostare il [limite delle autorizzazioni](access_policies_boundaries.md) per il ruolo.
**Per creare un ruolo per un AWS servizio da AWS CLI**
1. Il seguente comando `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` crea un ruolo denominato *Ruolo di test* e gli collega una policy di attendibilità:
`aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json`
1. Allega una politica di autorizzazioni gestite al ruolo: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html).
Ad esempio, il seguente comando `attach-role-policy` allega la policy gestita AWS denominata `ReadOnlyAccess` al ruolo IAM denominato `ReadOnlyRole`:
`aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole`
or
[Crea una politica di autorizzazioni in linea per il ruolo: aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
Per aggiungere una policy di autorizzazioni in linea, consulta l'esempio seguente:
`aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json`
1. (Facoltativo) Aggiungere attributi personalizzati al ruolo collegando tag: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
Per ulteriori informazioni, consulta [Gestione dei tag sui ruoli (AWS CLI o AWS API) IAM](id_tags_roles.md#id_tags_roles_procs-cli-api).
1. [(Facoltativo) Imposta il [limite delle autorizzazioni](access_policies_boundaries.md) per il ruolo: aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)
Il limite delle autorizzazioni controlla il numero massimo di autorizzazioni che è possibile concedere a un ruolo. I limiti delle autorizzazioni sono una funzionalità avanzata. AWS
Se intendi utilizzare il ruolo con Amazon EC2 o un altro AWS servizio che utilizza Amazon EC2, devi archiviare il ruolo in un profilo di istanza. Un profilo dell'istanza è un container per un ruolo che può essere associato a un'istanza Amazon EC2 quando viene avviato. Un profilo dell'istanza può contenere un solo ruolo e tale limite non può essere aumentato. Se crei il ruolo utilizzando Console di gestione AWS, il profilo dell'istanza viene creato per te con lo stesso nome del ruolo. Per ulteriori informazioni sui profili delle istanze, consulta [Usare profili dell'istanza](id_roles_use_switch-role-ec2_instance-profiles.md). Per informazioni su come avviare un'istanza EC2 con un ruolo, consulta [Controllo dell'accesso alle risorse Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances) nella *Guida per l'utente di Amazon EC2*.
**Per creare un profilo dell'istanza e memorizzarvi il ruolo (AWS CLI)**
1. Crea un profilo di istanza: [aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html)
1. Aggiungi il ruolo al profilo dell'istanza: [aws iam add-role-to-instance -profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html)
Il comando di AWS CLI esempio riportato di seguito illustra i primi due passaggi per la creazione di un ruolo e l'assegnazione delle autorizzazioni. Mostra inoltre i due passaggi necessari per creare un profilo dell'istanza e aggiungere il ruolo al profilo. Questa policy di attendibilità di esempio permette al servizio Amazon EC2 di assumere il ruolo e visualizzare il bucket `example_bucket` di Amazon S3. L'esempio presuppone inoltre l'uso un computer client con Windows e che l'interfaccia a riga di comando sia già configurata con le credenziali dell'account e la regione. Per ulteriori informazioni, vedere [Configurazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) dell'interfaccia a riga di comando. AWS
In questo esempio, è necessario includere la seguente policy di attendibilità nel primo comando al momento della creazione del ruolo. La policy di attendibilità consente al servizio Amazon EC2 di assumere il ruolo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
}
```
------
Quando si utilizza il secondo comando, è necessario collegare una policy di autorizzazione al ruolo. L'esempio di policy di autorizzazione seguente consente al ruolo di eseguire solo l'operazione `ListBucket` sul bucket `example_bucket` di Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
```
------
Per creare questo ruolo `Test-Role-for-EC2`, è innanzitutto necessario salvare la policy di attendibilità precedente con il nome `trustpolicyforec2.json` e la policy di autorizzazione precedente con il nome `permissionspolicyforec2.json` nella directory `policies` dell'unità `C:` locale. È quindi possibile utilizzare i comandi seguenti per creare il ruolo, collegare la policy, creare il profilo dell'istanza e aggiungere il ruolo al profilo dell'istanza.
```
# Create the role and attach the trust policy that allows EC2 to assume this role.
$ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json
# Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do.
$ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json
# Create the instance profile required by EC2 to contain the role
$ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3
# Finally, add the role to the instance profile
$ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2
```
Quando avvii l'istanza EC2, specifica il nome del profilo dell'istanza nella pagina **Configura i dettagli dell'istanza** se utilizzi la AWS console. Se utilizzi il comando della CLI `aws ec2 run-instances`, specifica il parametro `--iam-instance-profile`.
## Creazione di un ruolo per un servizio (AWS API)
La creazione di un ruolo dall' AWS API prevede diversi passaggi. Quando si usa la console per creare un ruolo, molti dei passaggi vengono eseguiti automaticamente, ma con l'API ogni passaggio deve essere eseguito esplicitamente dall'utente. È necessario creare il ruolo e quindi assegnargli una policy di autorizzazione. Se il servizio in uso è Amazon EC2, è necessario creare anche un profilo dell'istanza e aggiungervi il ruolo. Puoi anche scegliere di impostare il [limite delle autorizzazioni](access_policies_boundaries.md) per il ruolo.
**Creare un ruolo per un AWS servizio (AWS API)**
1. Crea un ruolo: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
Per la policy di affidabilità del ruolo, è possibile specificare una posizione del file.
1. Allega una politica di autorizzazioni gestite al ruolo: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
or
Crea una politica di autorizzazioni in linea per il ruolo: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
1. (Facoltativo) Aggiungi attributi personalizzati all'utente allegando tag: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
Per ulteriori informazioni, consulta [Gestione dei tag sugli utenti IAM (AWS CLI o AWS API)](id_tags_users.md#id_tags_users_procs-cli-api).
1. (Facoltativo) Imposta il [limite delle autorizzazioni per il ruolo](access_policies_boundaries.md): [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)
Il limite delle autorizzazioni controlla il numero massimo di autorizzazioni che è possibile concedere a un ruolo. I limiti delle autorizzazioni sono una funzionalità avanzata. AWS
Se intendi utilizzare il ruolo con Amazon EC2 o un altro AWS servizio che utilizza Amazon EC2, devi archiviare il ruolo in un profilo di istanza. Un profilo dell'istanza è un container per un ruolo. Ogni profilo dell'istanza può contenere un solo ruolo e tale limite non può essere superato. Se crei il ruolo in Console di gestione AWS, il profilo dell'istanza viene creato per te con lo stesso nome del ruolo. Per ulteriori informazioni sui profili delle istanze, consulta [Usare profili dell'istanza](id_roles_use_switch-role-ec2_instance-profiles.md). Per informazioni su come avviare un'istanza Amazon EC2 con un ruolo, consulta [Controllo dell'accesso alle risorse Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances) nella *Guida per l'utente di Amazon EC2*.
**Per creare un profilo di istanza e memorizzare il ruolo al suo interno (AWS API)**
1. Crea un profilo di istanza: [CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html)
1. Aggiungi il ruolo al profilo dell'istanza: [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html)
# Creare un ruolo collegato ai servizi
Un ruolo collegato ai servizi è un tipo univoco di ruolo IAM collegato direttamente a un servizio AWS . I ruoli collegati ai servizi sono predefiniti dal servizio e includono tutte le autorizzazioni richieste dal servizio per chiamare altri AWS servizi per conto dell'utente. Il servizio collegato definisce anche le modalità di creazione, modifica ed eliminazione di un ruolo collegato al servizio. Un servizio può creare o eliminare automaticamente il ruolo. È possibile che ti permetta di creare, modificare o eliminare il ruolo come parte di una procedura guidata o un processo nel servizio. Oppure potrebbe richiedere l'utilizzo di IAM per creare o eliminare il ruolo. Indipendentemente dal metodo, i ruoli collegati ai servizi semplificano la procedura di configurazione di un servizio poiché non dovrai più aggiungere manualmente le autorizzazioni necessarie ai servizi per completare le operazioni per tuo conto.
**Nota**
Ricorda che i ruoli di servizio sono diversi dai ruoli collegati ai servizi. Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che un servizio assume per eseguire operazioni per tuo conto. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall’interno di IAM. Per ulteriori informazioni, consulta [Create a role to delegate permissions to an Servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *Guida per l’utente IAM*. Un ruolo collegato al servizio è un tipo di ruolo di servizio collegato a un. Servizio AWS Il servizio può assumere il ruolo per eseguire un’operazione per tuo conto. I ruoli collegati al servizio vengono visualizzati nel tuo account Account AWS e sono di proprietà del servizio. Un amministratore IAM può visualizzare le autorizzazioni per i ruoli collegati al servizio, ma non modificarle.
Il servizio collegato definisce le autorizzazioni dei relativi ruoli collegati ai servizi e, a meno che non sia stato stabilito diversamente, solo quel servizio può assumere i ruoli. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni. Una policy delle autorizzazioni specifica non può essere collegata a un’altra entità IAM.
Prima di poter eliminare i ruoli, devi eliminare le risorse associate. Questo ti aiuta a evitare di rimuovere involontariamente l’autorizzazione ad accedere alle risorse.
**Suggerimento**
Per informazioni su quali servizi supportano i ruoli collegati ai servizi, consulta la pagina [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md) e cerca i servizi per cui è indicato **Sì **nella colonna **Ruolo collegato ai servizi**. Scegliere **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato al servizio per tale servizio.
## Autorizzazioni del ruolo collegato ai servizi
Per consentire a un utente o un ruolo di creare o modificare un ruolo collegato ai servizi, devi configurare le autorizzazioni per un'entità IAM (utente o ruolo).
**Nota**
L'ARN per un ruolo collegato ai servizi include un'entità principale del servizio, indicata nelle policy seguenti come `SERVICE-NAME.amazonaws.com`. Non cercate di indovinare il principale del servizio, perché fa distinzione tra AWS maiuscole e minuscole e il formato può variare da un servizio all'altro. Per visualizzare l'entità principale di un servizio, consulta la relativa documentazione del ruolo collegato al servizio.
**Per consentire a un'entità IAM di creare un ruolo specifico collegato ai servizi**
Aggiungi la policy seguente a un'entità IAM che deve creare il ruolo collegato ai servizi.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*",
"Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
]
}
```
------
**Come consentire a un'entità IAM di creare qualunque ruolo collegato ai servizi**
Aggiungi la seguente istruzione alla policy delle autorizzazioni per l'entità IAM che deve creare un ruolo collegato ai servizi o qualunque ruolo di servizio che include le policy di cui ha bisogno. Questa istruzione della policy non consente all'entità IAM di collegare una policy al ruolo.
```
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**Come consentire a un'entità IAM di modificare la descrizione di qualunque ruolo di servizio**
Aggiungi la seguente istruzione alla policy delle autorizzazioni per l'entità IAM che deve modificare la descrizione di un ruolo collegato ai servizi o qualunque ruolo di servizio.
```
{
"Effect": "Allow",
"Action": "iam:UpdateRoleDescription",
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**Come consentire a un'entità IAM di eliminare un ruolo collegato ai servizi specifico**
Aggiungi la seguente istruzione alla policy delle autorizzazioni per l'entità IAM che deve eliminare il ruolo collegato ai servizi.
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
```
**Come consentire a un'entità IAM di eliminare qualunque ruolo collegato ai servizi**
Aggiungi la seguente istruzione alla policy delle autorizzazioni per l'entità IAM che deve eliminare un ruolo collegato ai servizi ma non il ruolo di servizio.
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**Come consentire a un'entità IAM di passare un ruolo esistente al servizio**
Alcuni AWS servizi consentono di trasferire un ruolo esistente al servizio, anziché creare un nuovo ruolo collegato al servizio. Per eseguire questa operazione, un utente deve disporre delle autorizzazioni per *passare il ruolo* al servizio. Aggiungi l'istruzione seguente alla policy delle autorizzazioni per l'entità IAM che deve passare un ruolo. Questa istruzione della policy consente anche all'entità di visualizzare un elenco di ruoli da cui è possibile scegliere il ruolo da passare. Per ulteriori informazioni, consulta [Concedere a un utente le autorizzazioni per passare un ruolo a un servizio AWS](id_roles_use_passrole.md).
```
{
"Sid": "PolicyStatementToAllowUserToListRoles",
"Effect": "Allow",
"Action": ["iam:ListRoles"],
"Resource": "*"
},
{
"Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ"
}
```
## Autorizzazioni indirette con ruoli collegati al servizio
Le autorizzazioni concesse da un ruolo collegato ai servizi possono essere indirettamente trasferite ad altri utenti e ruoli. Quando un ruolo collegato al servizio viene utilizzato da un AWS servizio, tale ruolo può utilizzare le proprie autorizzazioni per chiamare altri servizi. AWS Ciò significa che gli utenti e i ruoli con le autorizzazioni per chiamare un servizio che utilizza un ruolo collegato al servizio possono avere accesso indiretto ai servizi a cui può accedere quel ruolo collegato al servizio.
Ad esempio, quando crei un'istanza database Amazon RDS, [un ruolo collegato ai servizi per RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html) viene creato automaticamente se non ne esiste già uno. Questo ruolo collegato al servizio consente a RDS di chiamare Amazon EC2, Amazon SNS, Amazon CloudWatch Logs e Amazon Kinesis per tuo conto. Se consenti agli utenti e ai ruoli del tuo account di modificare o creare database RDS, potrebbero interagire indirettamente con Amazon EC2, Amazon SNS, i log di Amazon Logs e le risorse CloudWatch Amazon Kinesis chiamando RDS, poiché RDS utilizzerebbe il suo ruolo collegato ai servizi per accedere a tali risorse.
### Metodi per creare un ruolo collegato ai servizi
Il metodo utilizzato per creare un ruolo collegato ai servizi dipende dal servizio. In alcuni casi, non devi creare manualmente un ruolo collegato ai servizi. Ad esempio, quando completi un'azione specifica (ad esempio la creazione di una risorsa) nel servizio, il servizio potrebbe creare il ruolo collegato ai servizi per te. O se stavi utilizzando un servizio prima di iniziare il supporto ai ruoli collegati ai servizi, allora il servizio potrebbe aver creato automaticamente il ruolo nel tuo account. Per ulteriori informazioni, consulta [Nel mio account è apparso un nuovo ruolo AWS](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared).
In altri casi, il servizio può supportare la creazione di un ruolo collegato ai servizi manualmente utilizzando la console di servizio, le API o la CLI. Per informazioni su quali servizi supportano i ruoli collegati ai servizi, consulta la pagina [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md) e cerca i servizi per cui è indicato **Sì **nella colonna **Ruolo collegato ai servizi**. Per scoprire se il servizio supporta la creazione del ruolo collegato ai servizi, selezionare il link **Sì** per visualizzare il ruolo collegato ai servizi per quel servizio.
Se il servizio non supporta la creazione del ruolo, è possibile utilizzare IAM per creare il ruolo collegato ai servizi.
**Importante**
I ruoli collegati ai servizi vengono conteggiati nel limite dei [Ruoli IAM in un Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities), ma se è stato raggiunto il limite puoi sempre creare i ruoli collegati ai servizi nel tuo account. Solo i ruoli collegati ai servizi possono superare il limite.
### Creazione di un ruolo collegato ai servizi (console)
Prima di creare un ruolo collegato ai servizi in IAM, scopri se il servizio collegato crea automaticamente i ruoli collegati ai servizi; inoltre, scopri se è possibile creare il ruolo dalla console del servizio, dall'API o dalla CLI.
**Come creare un ruolo collegato ai servizi (console)**
1. Accedi e apri la console IAM all'indirizzo. Console di gestione AWS [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nel pannello di navigazione della console IAM seleziona **Ruoli**. Quindi seleziona **Create role** (Crea ruolo).
1. Scegli il tipo di ruolo di **servizio AWS **.
1. Scegli il caso d'uso per il servizio. I casi d'uso sono definiti dal servizio in modo da includere la policy di attendibilità richiesta dal servizio. Quindi, seleziona **Successivo**.
1. Scegli una o più policy di autorizzazione da collegare al ruolo. A seconda del caso d'uso selezionato, il servizio può eseguire una di queste operazioni:
+ Definire le autorizzazioni utilizzate dal ruolo.
+ Consentire di scegliere tra un set limitato di autorizzazioni.
+ Consentire di scegliere qualsiasi autorizzazione.
+ Ti consente di non selezionare policy in questo momento, creare le policy successivamente e quindi collegarle al ruolo.
Seleziona la casella di controllo accanto alla policy che assegna le autorizzazioni desiderate per il ruolo, quindi scegli **Successivo**.
**Nota**
Le autorizzazioni specificate sono disponibili per qualsiasi entità che utilizza il ruolo. Per default, un ruolo non dispone di autorizzazioni.
1. Il grado di personalizzazione per **Nome ruolo** viene definito dal servizio. Se il servizio definisce il nome del ruolo, allora questa opzione non può essere modificata. In altri casi, il servizio può definire un prefisso per il ruolo e consentirti di inserire un suffisso opzionale.
Se possibile, inserisci il suffisso del nome del ruolo da aggiungere al nome predefinito. Il suffisso consente di identificare lo scopo del ruolo. I nomi dei ruoli devono essere univoci all'interno dell'account AWS . Non si distinguono per caso. Ad esempio, non è possibile creare ruoli denominati sia **\$1SAMPLE** che **\$1sample**. Poiché varie entità possono fare riferimento al ruolo, non è possibile modificare il nome del ruolo dopo averlo creato.
1. (Facoltativo) In **Description** (Descrizione), modifica la descrizione per il nuovo ruolo collegato ai servizi.
1. Non è possibile collegare tag ai ruoli collegati ai servizi durante la creazione. Per ulteriori informazioni sull'utilizzo dei tag in IAM, consultare [Tag per AWS Identity and Access Management le risorse](id_tags.md).
1. Rivedere il ruolo e scegliere **Crea ruolo**.
### Creazione di un ruolo collegato ai servizi (AWS CLI)
Prima di creare un ruolo collegato ai servizi in IAM, scopri se il servizio collegato crea automaticamente i ruoli collegati ai servizi e se è possibile creare il ruolo dalla CLI del servizio. Se la CLI del servizio non è supportata, puoi usare i comandi IAM per creare un ruolo collegato ai servizi con la policy di attendibilità e le policy in linea che il servizio richiede per assumere il ruolo.
**Per creare un ruolo collegato ai servizi (AWS CLI)**
Esegui il comando seguente:
```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com
```
### Creazione di un ruolo collegato al servizio (API)AWS
Prima di creare un ruolo collegato ai servizi in IAM, scopri se il servizio collegato crea automaticamente i ruoli collegati ai servizi e scopri se è possibile creare il ruolo dalle API del servizio. Se l'API del servizio non è supportata, puoi utilizzarla per creare un ruolo collegato al servizio con la policy di fiducia e le politiche in linea necessarie al servizio per assumere il ruolo. AWS
**Per creare un ruolo collegato al servizio (API)AWS **
Utilizzare la chiamata API [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html). Nella richiesta, specificare un nome del servizio di `SERVICE_NAME_URL.amazonaws.com`.
Ad esempio, per creare il ruolo collegato ai servizi **Lex Bots (Bot di Lex)**, utilizzare `lex.amazonaws.com`.
# Creazione di un ruolo per un provider di identità di terze parti
Puoi utilizzare provider di identità invece di creare utenti IAM nel tuo Account AWS. Con un provider di identità (IdP), puoi gestire le tue identità utente all'esterno AWS e concedere a queste identità utente esterne le autorizzazioni per accedere AWS alle risorse del tuo account. Per ulteriori informazioni sulla federazione e sui provider di identità, consultare [Provider di identità e federazione in AWS](id_roles_providers.md).
## Creazione di un ruolo per i principali federati OIDC e SAML (console)
Le procedure per la creazione di un ruolo dipendono dalla scelta dei provider di terze parti:
+ Per OpenID Connect (OIDC), consulta [Creare un ruolo per la federazione OpenID Connect (console)](id_roles_create_for-idp_oidc.md).
+ Per SAML 2.0, consulta [Creare un ruolo per una federazione SAML 2.0 (console)](id_roles_create_for-idp_saml.md).
## Creazione di un ruolo per l'accesso federato (AWS CLI)
Le procedure per creare un ruolo per il provider di identità supportato (OIDC o SAML) dalla AWS CLI sono identiche. La differenza consiste nel contenuto della policy di affidabilità creata in passaggi preliminari. Inizia seguendo le fasi descritte nella sezione dei **prerequisiti** per il tipo di provider in uso:
+ Per un provider OIDC, consulta [Prerequisiti per la creazione di un ruolo per OIDC](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites).
+ Per un provider SAML, consulta [Prerequisiti per la creazione di un ruolo per SAML](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites).
La creazione di un ruolo da richiede diversi passaggi. AWS CLI Quando si utilizza la console per creare un ruolo, molti passaggi vengono eseguiti automaticamente, ma con la console AWS CLI è necessario eseguire esplicitamente ogni passaggio da soli. È necessario creare il ruolo e quindi assegnargli una policy di autorizzazione. Puoi anche scegliere di impostare il [limite delle autorizzazioni](access_policies_boundaries.md) per il ruolo.
**Per creare un ruolo (AWS CLI)**
1. Creare un ruolo: [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)
1. [Allega una politica di autorizzazioni al ruolo: aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)
or
[Crea una politica di autorizzazioni in linea per il ruolo: aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
1. (Facoltativo) Aggiungere attributi personalizzati al ruolo collegando tag: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
Per ulteriori informazioni, consulta [Gestione dei tag sui ruoli (AWS CLI o AWS API) IAM](id_tags_roles.md#id_tags_roles_procs-cli-api).
1. [(Facoltativo) Imposta il [limite delle autorizzazioni](access_policies_boundaries.md) per il ruolo: aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)
Il limite delle autorizzazioni controlla il numero massimo di autorizzazioni che è possibile concedere a un ruolo. I limiti delle autorizzazioni sono una funzionalità avanzata. AWS
L'esempio seguente mostra i primi due passaggi, più comuni, per la creazione di un ruolo del provider di identità in un ambiente semplice. Questo esempio permette agli utenti dell'account `123456789012` di assumere il ruolo e visualizzare il bucket `example_bucket` di Amazon S3. Questo esempio presuppone inoltre che tu stia eseguendo Windows AWS CLI su un computer che esegue Windows e che lo abbia già configurato AWS CLI con le tue credenziali. Per ulteriori informazioni, consultare la pagina relativa alla [configurazione di AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).
La policy di attendibilità di esempio riportata di seguito è progettata per un'app per dispositivi mobili in cui l'utente accede tramite Amazon Cognito. In questo esempio, *us-east:12345678-ffff-ffff-ffff-123456* rappresenta l'ID del pool di identità assegnato da Amazon Cognito.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "RoleForCognito",
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
}
}
```
------
La policy delle autorizzazioni seguente consente agli utenti che assumono il ruolo di eseguire solo l'operazione `ListBucket` sul bucket `example_bucket` di Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
```
------
Per creare questo ruolo `Test-Cognito-Role`, è prima necessario salvare la policy di attendibilità precedente con il nome `trustpolicyforcognitofederation.json` e la policy di autorizzazione precedente con il nome `permspolicyforcognitofederation.json` nella cartella `policies` dell'unità `C:` locale. È quindi possibile utilizzare i comandi seguenti per creare il ruolo e collegare la policy inline.
```
# Create the role and attach the trust policy that enables users in an account to assume the role.
$ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json
# Attach the permissions policy to the role to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json
```
## Creazione di un ruolo per l'accesso federato (API)AWS
Le procedure per creare un ruolo per il provider di identità supportato (OIDC o SAML) dalla AWS CLI sono identiche. La differenza consiste nel contenuto della policy di affidabilità creata in passaggi preliminari. Inizia seguendo le fasi descritte nella sezione dei **prerequisiti** per il tipo di provider in uso:
+ Per un provider OIDC, consulta [Prerequisiti per la creazione di un ruolo per OIDC](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites).
+ Per un provider SAML, consulta [Prerequisiti per la creazione di un ruolo per SAML](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites).
**Per creare un ruolo (AWS API)**
1. Crea un ruolo: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
1. Allega una politica di autorizzazioni al ruolo: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
or
Crea una politica di autorizzazioni in linea per il ruolo: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
1. (Facoltativo) Aggiungi attributi personalizzati all'utente allegando tag: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
Per ulteriori informazioni, consulta [Gestione dei tag sugli utenti IAM (AWS CLI o AWS API)](id_tags_users.md#id_tags_users_procs-cli-api).
1. (Facoltativo) Imposta il [limite delle autorizzazioni per il ruolo](access_policies_boundaries.md): [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)
Il limite delle autorizzazioni controlla il numero massimo di autorizzazioni che è possibile concedere a un ruolo. I limiti delle autorizzazioni sono una funzionalità avanzata. AWS
# Creare un ruolo per la federazione OpenID Connect (console)
Puoi utilizzare i provider di identità federati OpenID Connect (OIDC) invece di creare utenti nel tuo. AWS Identity and Access Management Account AWS Con un provider di identità (IdP), puoi gestire le tue identità utente all'esterno AWS e concedere a queste identità utente esterne le autorizzazioni per accedere AWS alle risorse del tuo account. Per ulteriori informazioni sulla federazione e, vedere. IdPs [Provider di identità e federazione in AWS](id_roles_providers.md)
## Prerequisiti per la creazione di un ruolo per OIDC
Prima di poter creare un ruolo per la federazione OIDC, devi completare i seguenti passaggi obbligatori.
**Per prepararsi alla creazione di un ruolo per la federazione OIDC**
1. Registrati con uno o più servizi che offrono l'identità OIDC federata. Se stai creando un'app che richiede l'accesso alle tue AWS risorse, configurala anche con le informazioni del provider. Al momento della registrazione, il gestore fornisce un ID applicazione o destinatario univoco per l'app. Provider diversi utilizzano una terminologia diversa per questo processo. Questa guida utilizza il termine*configurare* per il processo di identificazione dell'applicazione con il provider. È possibile configurare più app con ogni provider o più provider con una sola app. Consulta le informazioni sull'utilizzo degli IdP specificate di seguito:
+ [Centro Sviluppatori di Login with Amazon](https://login.amazon.com/)
+ [Aggiunta dell'accesso a Facebook a un'app o a un sito Web](https://developers.facebook.com/docs/facebook-login/v2.1) sul sito degli sviluppatori di Facebook.
+ [Utilizzo della OAuth versione 2.0 per il login (OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login) sul sito degli sviluppatori di Google.
1. Dopo aver ricevuto le informazioni richieste dall'IdP, crea un IdP in IAM. Per ulteriori informazioni, consulta [Creare un provider di identità OpenID Connect (OIDC) in IAM](id_roles_providers_create_oidc.md).
**Importante**
Se utilizzi un IdP OIDC di Google, Facebook o Amazon Cognito, non occorre creare un IdP IAM separato nella Console di gestione AWS. Questi provider di identità OIDC sono già integrati AWS e possono essere utilizzati. Ignora questa fase e vai alla fase successiva per creare nuovi ruoli utilizzando l'IdP.
1. Prepara le policy per il ruolo che verrà assunto dagli utenti autenticati dal provider di identità. Come qualsiasi altro ruolo, anche il ruolo per un'app per dispositivi mobili include due policy. Una è la policy di affidabilità, che specifica chi può assumere il ruolo. L'altra è la policy di autorizzazione, che specifica le operazioni e le risorse AWS a cui l'app per dispositivi mobili può accedere o meno.
Per il Web IdPs, ti consigliamo di utilizzare [Amazon Cognito](https://aws.amazon.com/cognito/) per gestire le identità. In tal caso, si utilizza una policy di attendibilità simile all'esempio seguente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"},
"ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"}
}
}
}
```
------
Sostituisci `us-east-2:12345678-abcd-abcd-abcd-123456` con l'ID del pool di identità che ti ha assegnato Amazon Cognito.
Nella configurazione manuale di un IdP OIDC, al momento della creazione della policy di attendibilità occorre utilizzare tre valori che garantiscono che solo l'app in questione possa assumere quel ruolo:
+ Per l'elemento `Action`, si utilizza l'operazione `sts:AssumeRoleWithWebIdentity`.
+ Per l'elemento `Principal`, usa la stringa `{"Federated":providerUrl/providerArn}`.
+ Per alcuni OIDC comuni IdPs, si tratta di un URL. `providerUrl` Gli esempi seguenti includono metodi per specificare il principale per alcuni casi comuni: IdPs
`"Principal":{"Federated":"cognito-identity.amazonaws.com"}`
`"Principal":{"Federated":"www.amazon.com"}`
`"Principal":{"Federated":"graph.facebook.com"}`
`"Principal":{"Federated":"accounts.google.com"}`
+ Per gli altri gestori OIDC, utilizza il nome della risorsa Amazon (ARN) dell'IdP OIDC creato in [Step 2](#idpoidcstep2), come nell'esempio seguente:
`"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}`
+ Per l'elemento `Condition`, si utilizza una condizione `StringEquals` per limitare le autorizzazioni. È necessario testare l'ID del pool di identità per Amazon Cognito o l'ID app per altri provider. L'ID del pool di identità dovrebbe corrispondere all'ID app che hai ricevuto durante la configurazione dell'app con l'IdP. Questa corrispondenza tra i IDs garantisce che la richiesta provenga dalla tua app.
**Nota**
I ruoli IAM per i pool di identità di Amazon Cognito si affidano al principale del servizio `cognito-identity.amazonaws.com` per assumere il ruolo. I ruoli di questo tipo devono contenere almeno una chiave di condizione per limitare i principali che possono assumere il ruolo.
Considerazioni aggiuntive si applicano ai pool di identità di Amazon Cognito che assumono [ruoli IAM su più account](access_policies-cross-account-resource-access.md). Le policy di attendibilità di questi ruoli devono accettare il principale del servizio `cognito-identity.amazonaws.com` e devono contenere la chiave di condizione `aud` per limitare l'assunzione di ruoli agli utenti dei pool di identità previsti. Una policy che considera attendibili i pool di identità di Amazon Cognito senza questa condizione comporta il rischio che un utente proveniente da un pool di identità non intenzionale possa assumere il ruolo. Per ulteriori informazioni, consulta [Policy di attendibilità per i ruoli IAM nell'autenticazione di base (classica)](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies) nella *Guida per gli sviluppatori di Amazon Cognito*.
Crea un elemento condizione simile agli esempi seguenti, a seconda dell'IdP in uso:
`"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}`
`"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}`
`"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}`
`"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}`
Per i provider OIDC, si utilizza l'URL completo del provider di identità OIDC con la chiave di contesto `aud`, come nell'esempio seguente:
`"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}`
**Nota**
I valori per il principale nella policy di attendibilità per il ruolo sono specifici dell'IdP. Un ruolo per OIDC può specificare solo un principale. Pertanto, se l'app per dispositivi mobili consente agli utenti di effettuare l'accesso da più di un IdP, devi creare un ruolo separato per ogni IdP da supportare. Crea policy di attendibilità separate per ogni IdP.
Se un utente utilizza un'app per dispositivi mobili per accedere da Login with Amazon, si applica la policy di attendibilità di esempio riportata di seguito. Nell'esempio, *amzn1.application-oa2-123456* rappresenta l'ID dell'app che Amazon assegna quando hai configurato l'app utilizzando Login with Amazon.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForLoginWithAmazon",
"Effect": "Allow",
"Principal": {"Federated": "www.amazon.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}
}]
}
```
------
Se un utente utilizza un'app per dispositivi mobili per accedere da Facebook, si applica la policy di attendibilità di esempio riportata di seguito. In questo esempio, *111222333444555* rappresenta l'ID dell'app assegnato da Facebook.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForFacebook",
"Effect": "Allow",
"Principal": {"Federated": "graph.facebook.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}
}]
}
```
------
Se un utente utilizza un'app per dispositivi mobili per accedere da Google, si applica la policy di attendibilità di esempio riportata di seguito. In questo esempio, *666777888999000* rappresenta l'ID dell'app assegnato da Google.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForGoogle",
"Effect": "Allow",
"Principal": {"Federated": "accounts.google.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}}
}]
}
```
------
Se un utente utilizza un'app per dispositivi mobili per accedere da Amazon Cognito, si applica la policy di attendibilità di esempio riportata di seguito. In questo esempio, *us-east:12345678-ffff-ffff-ffff-123456* rappresenta l'ID del pool di identità assegnato da Amazon Cognito.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForCognito",
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
}]
}
```
------
## Creazione di un ruolo per OIDC
Una volta completati i prerequisiti, puoi creare il ruolo in IAM. *Per i provider di identità OpenID Connect (OIDC) condivisi riconosciuti, IAM richiede una valutazione esplicita di affermazioni specifiche in JSON Web Tokens (IdPs), note come controlli del provider di identità. JWTs* *Per ulteriori informazioni su quali OIDC dispongono dei controlli dei provider di identità, consulta. IdPs * [Controlli tramite provider di identità per i provider OIDC condivisi](id_roles_providers_oidc_secure-by-default.md)
Nella procedura seguente viene descritto come creare il ruolo per la federazione OIDC nella Console di gestione AWS. Per creare un ruolo dall' AWS API AWS CLI or, consulta le procedure disponibili all'indirizzo. [Creazione di un ruolo per un provider di identità di terze parti](id_roles_create_for-idp.md)
**Importante**
Se utilizzi Amazon Cognito, utilizza la console di Amazon Cognito per configurare i ruoli. In caso contrario, usa la console IAM per creare un ruolo per la federazione OIDC.
**Per creare un ruolo IAM per la federazione OIDC**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel riquadro di navigazione, scegli **Ruoli**, quindi **Crea ruolo**.
1. Scegli **Identità Web** come tipo di entità attendibile e seleziona **Avanti**.
1. Per **Identity provider** (Gestore dell'identità digitale [IdP]), scegli l'IdP per il ruolo:
+ Se vuoi creare un ruolo per un singolo IdP Web, scegli **Login with Amazon**, **Facebook** o **Google**.
**Nota**
Devi creare un ruolo separato per ogni IdP che intendi supportare.
+ Se vuoi creare un ruolo per uno scenario avanzato per Amazon Cognito, scegli **Amazon Cognito**.
**Nota**
Devi creare manualmente un ruolo da utilizzare con Amazon Cognito solo quando operi in uno scenario avanzato. In caso contrario, i ruoli possono essere creati da Amazon Cognito. Per ulteriori informazioni su Amazon Cognito, consulta la pagina [Provider di identità esterni di pool di identità (identità federate)](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) nella *Guida per gli sviluppatori di Amazon Cognito*.
+ Se desideri creare un ruolo per GitHub Actions, devi iniziare aggiungendo il provider GitHub OIDC a IAM. **Dopo aver aggiunto il provider GitHub OIDC a IAM, scegli token.actions.githubusercontent.com.**
**Nota**
Per informazioni su come configurare AWS il provider OIDC GitHub di Trust come identità federata, consulta [GitHub Docs - Configuring OpenID Connect in](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) Amazon Web Services. Per informazioni sulle best practice per limitare l'accesso ai ruoli associati a IAM IdP GitHub for, [Configurazione di un ruolo per il provider di GitHub identità OIDC](#idp_oidc_Create_GitHub) consulta questa pagina.
+ Se desideri creare un ruolo per HashiCorp Cloud Platform (HCP) Terraform, devi iniziare aggiungendo il provider Terraform OIDC a IAM. Dopo aver aggiunto il provider OIDC Terraform a IAM, scegli **app.terraform.io**.
**Importante**
Il provider IAM roles for HashiCorp Cloud Platform (HCP) Terraform OIDC deve valutare la chiave delle condizioni IAM, nella policy di fiducia dei ruoli. `app.terraform.io:sub` Questa chiave di condizione limita le organizzazioni, i progetti, gli spazi di lavoro o le fasi di esecuzione di HCP Terraform in grado di assumere il ruolo. Senza questa condizione chiave, la vostra policy di fiducia concede l'accesso al vostro ruolo e alle vostre AWS risorse da parte di identità esterne all'organizzazione, il che non è in linea con il principio del privilegio minimo.
Se imposti o modifichi una politica di fiducia per un ruolo associato al provider HCP Terraform OIDC nel tuo AWS account, ma non valuti la chiave di condizione IAM, riceverai un errore. `app.terraform.io:sub` Inoltre, AWS STS negherà le richieste di autorizzazione se la policy di attendibilità del ruolo non valuta questa chiave di condizione.
1. Le informazioni richieste variano in base al provider OIDC scelto.
+ Inserisci l'identificatore per l'applicazione. L'etichetta relativa all'identificatore cambia in base al gestore scelto:
+ Se vuoi creare un ruolo per Login with Amazon, inserisci l'ID app nella casella **Application ID** (ID applicazione).
+ Se vuoi creare un ruolo per Facebook, inserisci l'ID app nella casella **Application ID** (ID applicazione).
+ Se vuoi creare un ruolo per Google, inserisci il nome del destinatario nella casella **Audience** (Destinatario).
+ Se vuoi creare un ruolo per Amazon Cognito, inserisci l'ID del pool di identità che hai creato per le applicazioni Amazon Cognito nella casella **Identity Pool ID** (ID pool di identità).
+ Se desideri creare un ruolo per GitHub Actions, inserisci i seguenti dettagli:
+ Per **Pubblico**, scegli `sts.amazonaws.com`.
+ Per **GitHub l'organizzazione**, inserisci il nome GitHub dell'organizzazione. Il nome GitHub dell'organizzazione è obbligatorio e deve essere alfanumerico, compresi i trattini (-). Non puoi usare caratteri jolly (\$1 e?) nel nome dell' GitHub organizzazione.
+ (Facoltativo) Per il **GitHub repository**, inserisci il nome del GitHub repository. Se non specifichi un valore, viene utilizzato un carattere jolly (`*`) per impostazione predefinita.
+ (Facoltativo) Per il **GitHub ramo**, inserisci il nome del GitHub ramo. Se non specifichi un valore, viene utilizzato un carattere jolly (`*`) per impostazione predefinita.
+ Se desideri creare un ruolo per HashiCorp Cloud Platform (HCP) Terraform, inserisci i seguenti dettagli:
+ Per **Pubblico**, scegli `aws.workload.identity`.
+ Per **Organizzazione**, inserisci il nome dell'organizzazione. È possibile specificare un carattere jolly (`*`) per tutte le organizzazioni.
+ Per **Progetto**, inserisci il nome del progetto. È possibile specificare un carattere jolly (`*`) per tutti i progetti.
+ In **Spazio di lavoro**, immetti un nome per lo spazio di lavoro. È possibile specificare un carattere jolly (`*`) per tutti gli spazi di lavoro.
+ Per **Fase di esecuzione**, inserisci il nome della fase di esecuzione. È possibile specificare un carattere jolly (`*`) per tutte le fasi di esecuzione.
1. (Facoltativo) In **Condizione (facoltativo)** scegli **Aggiungi condizione**per creare condizioni aggiuntive che devono essere soddisfatte prima che gli utenti dell'applicazione possano utilizzare le autorizzazioni concesse dal ruolo. Ad esempio, puoi aggiungere una condizione che conceda l'accesso alle AWS risorse solo per uno specifico ID utente IAM. Puoi anche aggiungere condizioni alla policy di attendibilità dopo la creazione del ruolo. Per ulteriori informazioni, consulta [Aggiornamento di una policy di attendibilità del ruolo](id_roles_update-role-trust-policy.md).
1. Verifica le informazioni su OIDC, quindi seleziona **Successivo**.
1. IAM include un elenco delle politiche AWS gestite e gestite dai clienti nel tuo account. Seleziona la policy delle autorizzazioni da utilizzare o scegli **Create policy** (Crea policy) per aprire una nuova scheda del browser e creare una nuova policy da zero. Per ulteriori informazioni, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start). Una volta creata la policy, chiudere la scheda e tornare alla scheda originale. Seleziona la casella di controllo accanto alle policy di autorizzazione che si desidera abbiano gli utenti OIDC. È anche possibile non selezionare le policy ora e collegarle al ruolo in un secondo momento. Per default, un ruolo non dispone di autorizzazioni.
1. (Facoltativo) Impostare un [limite delle autorizzazioni](access_policies_boundaries.md). Questa è una caratteristica avanzata.
Apri la sezione **Permissions boundary** (Limite delle autorizzazioni) e scegli **Use a permissions boundary to control the maximum role permissions** (Usa un limite delle autorizzazioni per controllare il numero massimo di autorizzazioni del ruolo). Selezionare la policy da utilizzare per il limite delle autorizzazioni.
1. Scegli **Next (Successivo)**.
1. In **Role name**, (Nome ruolo), inserisci un nome. I nomi dei ruoli devono essere univoci all'interno del tuo Account AWS. Non fanno distinzione tra maiuscole e minuscole. Ad esempio, non è possibile creare ruoli denominati sia **PRODROLE** sia **prodrole**. Poiché altre AWS risorse potrebbero fare riferimento al ruolo, non puoi modificare il nome del ruolo dopo averlo creato.
1. (Facoltativo) In **Description** (Descrizione), inserisci una descrizione per il nuovo ruolo.
1. Per modificare i casi d'uso e le autorizzazioni per il ruolo, scegli **Edit** (Modifica) nelle sezioni **Step 1: Select trusted entities** (Fase 1: seleziona le entità attendibili) o **Step 2: Add permissions** (Fase 2: aggiungi autorizzazioni).
1. (Facoltativo) Per aggiungere metadati al ruolo, collegare 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. Rivedere il ruolo e scegliere **Crea ruolo**.
## Configurazione di un ruolo per il provider di GitHub identità OIDC
Se si utilizza GitHub come provider di identità (IdP) OpenID Connect (OIDC), la best practice consiste nel limitare le entità che possono assumere il ruolo associato all'IDP IAM. Quando includi una dichiarazione di condizione nella policy di fiducia, puoi limitare il ruolo a un' GitHuborganizzazione, un repository o una filiale specifici. Puoi usare la chiave di condizione `token.actions.githubusercontent.com:sub` con operatori di condizione delle stringhe per limitare l'accesso. Ti consigliamo di limitare la condizione a un insieme specifico di repository o filiali all'interno dell'organizzazione GitHub . Per informazioni su come configurare AWS l'OIDC GitHub di To Trust come identità federata, consulta [GitHub Docs - Configuring OpenID Connect in](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) Amazon Web Services.
Se utilizzi GitHub ambienti in flussi di lavoro operativi o in policy OIDC, ti consigliamo vivamente di aggiungere regole di protezione all'ambiente per una maggiore sicurezza. Utilizza i rami e i tag di implementazione per limitare i rami e i tag che possono essere implementati nell'ambiente. Per ulteriori informazioni sulla configurazione degli ambienti con regole di protezione, consulta [i rami e i tag di distribuzione](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags) nell'articolo *Utilizzo degli ambienti GitHub* per la distribuzione.
Quando GitHub OIDC IdP è il Principal affidabile per il tuo ruolo, IAM verifica la condizione della policy di fiducia del ruolo per verificare che la chiave della condizione `token.actions.githubusercontent.com:sub` sia presente e che il suo valore non sia solo un carattere jolly (\$1 e?) o null. IAM esegue questo controllo quando la policy di attendibilità viene creata o aggiornata. Se la chiave di condizione `token.actions.githubusercontent.com:sub` non è presente o il valore della chiave non soddisfa i criteri di valore indicati, la richiesta avrà esito negativo e restituirà un errore.
**Importante**
Se non limiti la chiave di condizione a un'organizzazione o `token.actions.githubusercontent.com:sub` a un repository specifici, GitHub le azioni di organizzazioni o repository al di fuori del tuo controllo possono assumere ruoli associati all' GitHub IdP IAM nel tuo account. AWS
L'esempio seguente di policy di fiducia limita l'accesso all' GitHub organizzazione, al repository e alla filiale definiti. Il `token.actions.githubusercontent.com:sub` valore della chiave di condizione nell'esempio seguente è il formato predefinito del valore dell'oggetto documentato da. GitHub
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
}
}
}
]
}
```
------
La condizione di esempio seguente limita l'accesso all' GitHub organizzazione e all'archivio definiti, ma concede l'accesso a qualsiasi ramo all'interno del repository.
```
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
}
}
```
La condizione di esempio seguente limita l'accesso a qualsiasi repository o ramo all'interno dell'organizzazione definita. GitHub Si consiglia di limitare la chiave di condizione `token.actions.githubusercontent.com:sub` a un valore specifico che limiti l'accesso ad GitHub Actions dall'interno GitHub dell'organizzazione.
```
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*"
}
}
```
Per ulteriori informazioni sulle chiavi di federazione OIDC disponibili per i controlli delle condizioni nelle policy, consulta [Chiavi disponibili per la federazione AWS OIDC](reference_policies_iam-condition-keys.md#condition-keys-wif).
# Creare un ruolo per una federazione SAML 2.0 (console)
Puoi utilizzare la federazione SAML 2.0 invece di creare utenti IAM nel tuo Account AWS. Con un provider di identità (IdP), puoi gestire le tue identità utente all'esterno AWS e concedere a queste identità utente esterne le autorizzazioni per accedere AWS alle risorse del tuo account. Per ulteriori informazioni sulla federazione e sui provider di identità, consultare [Provider di identità e federazione in AWS](id_roles_providers.md).
**Nota**
Per migliorare la resilienza della federazione, ti consigliamo di configurare l'IdP e la federazione AWS per supportare più endpoint di accesso SAML. Per i dettagli, consulta l'articolo del AWS Security Blog [Come utilizzare gli endpoint SAML regionali per](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover) il failover.
## Prerequisiti per la creazione di un ruolo per SAML
Prima di creare un ruolo per la federazione SAML 2.0, devi completare i seguenti passaggi obbligatori.
**Preparazione per la creazione di un ruolo per la federazione SAML 2.0**
1. Prima di creare un ruolo per la federazione basata su SAML, devi creare un provider SAML in IAM. Per ulteriori informazioni, consulta [Creare un provider di identità SAML in IAM](id_roles_providers_create_saml.md).
1. Prepara le policy per il ruolo che verrà assunto dagli utenti autenticati con SAML 2.0. Come qualsiasi altro ruolo, anche i ruoli per la federazione SAML includono due policy. Una è la policy di attendibilità del ruolo, che specifica chi può assumere il ruolo. L'altra è la politica di autorizzazione IAM che specifica le AWS azioni e le risorse a cui è consentito o negato l'accesso al principale federato SAML.
Al momento della creazione della policy di attendibilità per il ruolo, devi utilizzare tre valori che garantiscono che solo la tua applicazione possa assumere il ruolo:
+ Per l'elemento `Action`, si utilizza l'operazione `sts:AssumeRoleWithSAML`.
+ Per l'elemento `Principal`, usa la stringa `{"Federated":ARNofIdentityProvider}`. Sostituire `ARNofIdentityProvider` con l'ARN del [provider di identità SAML](id_roles_providers_saml.md) creato in [Step 1](#idpsamlstep1).
+ Per l’elemento `Condition`, utilizza una condizione `StringEquals` per verificare che l’attributo `saml:aud` della risposta SAML corrisponda all’URL visualizzato dal browser quando si accede alla console. L’URL dell’endpoint di accesso corrisponde all’attributo destinatario SAML del provider di identità. Puoi includere l'accesso URLs all'interno di aree geografiche particolari. AWS consiglia di utilizzare gli endpoint regionali anziché l'endpoint globale per migliorare la resilienza della federazione. [Per un elenco dei *region-code* valori possibili, consulta la colonna **Regione** negli AWS endpoint di accesso.](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)
Se è richiesta la crittografia SAML, l’URL di accesso deve includere l’identificatore univoco che AWS assegna al provider SAML. Puoi visualizzare l’identificatore univoco selezionando il provider di identità nella console IAM per visualizzare la pagina dei dettagli.
`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`
L'esempio seguente mostra una policy di affidabilità concepita per un utente federato SAML:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRoleWithSAML",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME"
},
"Condition": {
"StringEquals": {
"SAML:aud": "https://region-code.signin.aws.amazon.com/saml"
}
}
}
}
```
------
Sostituisci l'ARN principale con l'ARN effettivo del provider SAML, creato in IAM. L'ARN include l'ID account e il nome del provider.
## Creazione di un ruolo per SAML
Dopo aver completato i passaggi dei prerequisiti, è possibile creare il ruolo per la federazione basata su SAML.
**Per creare un ruolo per una federazione basata su SAML**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nel pannello di navigazione della console IAM, scegli **Ruoli** e quindi **Crea ruolo**.
1. Selezionare il tipo di ruolo **SAML 2.0 federation (Federazione SAML 2.0)**.
1. In **Select a SAML provider** (Seleziona un gestore dell'identità digitale SAML), scegli il gestore per il ruolo.
1. Selezionare il metodo di livello di accesso SAML 2.0.
+ Scegli **Consenti solo l'accesso programmatico** per creare un ruolo che può essere assunto a livello di codice dall' AWS API oppure. AWS CLI
+ Scegli **Consenti Console di gestione AWS accesso e programmazione** per creare un ruolo che può essere assunto a livello di codice e da. Console di gestione AWS
I due comandi sono simili, ma il ruolo che può essere assunto anche tramite console include una policy di affidabilità con una condizione particolare. Tale condizione verifica in modo esplicito che il destinatario SAML (attributo `SAML:aud`) sia impostato sull’endpoint di accesso di AWS per il tuo provider SAML.
1. La procedura per definire gli attributi varia a seconda del tipo di accesso.
+ Se si sta creando un ruolo per l'accesso programmatico, scegliere un attributo dall'elenco **Attributo**. Dopodiché, nella casella **Value** (Valore), inserisci un valore da includere nel ruolo. In questo modo, l'accesso al ruolo viene limitato agli utenti dal provider di identità la cui risposta di autenticazione SAML (asserzione) includa gli attributi specificati. Per fare in modo che il ruolo sia limitato a un sottoinsieme di utenti all'interno dell'organizzazione, specificare almeno un attributo.
+ Se stai creando un ruolo per scopi programmatici e di Console di gestione AWS accesso, la sezione **Endpoint di accesso** definisce l'URL visualizzato dal browser quando accedi alla console. Questo endpoint è l’attributo destinatario SAML del tuo provider di identità, che corrisponde alla chiave di contesto [`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml). Per ulteriori informazioni, consulta [Configurare le asserzioni SAML per la risposta di autenticazione](id_roles_providers_create_saml_assertions.md).
1. Scegli **Endpoint regionali** o **Endpoint non regionali**. Ti consigliamo di utilizzare più endpoint di accesso SAML regionali per migliorare la resilienza della federazione.
1. Per **le regioni**, scegli le aree che il tuo provider SAML supporta per l'accesso. AWS
1. **Affinché l'accesso URLs includa identificatori univoci**, seleziona se gli endpoint di accesso includono gli AWS identificatori univoci assegnati al tuo provider di identità SAML. Questa opzione è necessaria per le asserzioni SAML crittografate. Per ulteriori informazioni, consulta [Federazione SAML 2.0](id_roles_providers_saml.md).
1. Per aggiungere ulteriori condizioni relative agli attributi alla policy di attendibilità, scegli **Condition (optional)** (Condizione [facoltativo]), seleziona la condizione aggiuntiva e specifica un valore.
**Nota**
L'elenco include gli attributi SAML più comunemente utilizzati. IAM supporta attributi aggiuntivi che puoi usare per creare condizioni. Per un elenco degli attributi supportati, consulta [Chiavi disponibili per la federazione SAML](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml). Se si necessita di una condizione per un attributo SAML supportato che non è nell'elenco, è possibile aggiungere tale condizione manualmente. A tale scopo, modificare la policy di attendibilità dopo aver creato il ruolo.
1. Verifica le informazioni di attendibilità di SAML 2.0, quindi scegli **Next** (Successivo).
1. IAM include un elenco delle politiche AWS gestite e gestite dai clienti nel tuo account. Seleziona la policy delle autorizzazioni da utilizzare o scegli **Create policy** (Crea policy) per aprire una nuova scheda del browser e creare una nuova policy da zero. Per ulteriori informazioni, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start). Una volta creata la policy, chiudere la scheda e tornare alla scheda originale. Seleziona la casella di controllo accanto alle policy di autorizzazione che desideri concedere agli utenti federati SAML. È anche possibile non selezionare le policy ora e collegarle al ruolo in un secondo momento. Per default, un ruolo non dispone di autorizzazioni.
1. (Facoltativo) Impostare un [limite delle autorizzazioni](access_policies_boundaries.md). Questa è una caratteristica avanzata.
Apri la sezione **Permissions boundary** (Limite delle autorizzazioni) e scegli **Use a permissions boundary to control the maximum role permissions** (Usa un limite delle autorizzazioni per controllare il numero massimo di autorizzazioni del ruolo). Selezionare la policy da utilizzare per il limite delle autorizzazioni.
1. Scegli **Next (Successivo)**.
1. Scegli **Prossimo: Rivedi**.
1. In **Role name**, (Nome ruolo), inserisci un nome. I nomi dei ruoli devono essere univoci all'interno del tuo Account AWS. Non si distinguono per caso. Ad esempio, non è possibile creare ruoli denominati sia **PRODROLE** che **prodrole**. Poiché altre AWS risorse potrebbero fare riferimento al ruolo, non è possibile modificare il nome del ruolo dopo che è stato creato.
1. (Facoltativo) In **Description** (Descrizione), inserisci una descrizione per il nuovo ruolo.
1. Scegli **Edit** (Modifica) nelle sezioni **Step 1: Select trusted entities** (Fase 1: seleziona le entità attendibili) o **Step 2: Add permissions** (Fase 2: aggiungi autorizzazioni) per modificare i casi d'uso e le autorizzazioni per il ruolo.
1. (Facoltativo) Aggiungere 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. Rivedere il ruolo e scegliere **Crea ruolo**.
Una volta creato il ruolo, è possibile completare la relazione di trust SAML configurando il software provider di identità con informazioni su AWS. Queste informazioni includono i ruoli che devono utilizzare gli utenti federati SAML. Tale operazione viene definita configurazione della relazione di trust fra IdP e AWS. Per ulteriori informazioni, consulta [Configurare il provider di identità SAML 2.0 con una relazione di attendibilità della parte affidabile e aggiunta di attestazioni](id_roles_providers_create_saml_relying-party.md).
# Creare un ruolo utilizzando policy di attendibilità personalizzate
Puoi creare una politica di fiducia personalizzata per delegare l'accesso e consentire ad altri di eseguire azioni nel tuo Account AWS. Per ulteriori informazioni, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start).
Per informazioni su come utilizzare i ruoli per delegare le autorizzazioni, consultare [Termini e concetti dei ruoli](id_roles.md#id_roles_terms-and-concepts).
## Creazione di un ruolo IAM utilizzando una policy di attendibilità personalizzata (console)
Puoi utilizzare il Console di gestione AWS per creare un ruolo che un utente IAM può assumere. Ad esempio, supponiamo che l'organizzazione disponga di più Account AWS elementi per isolare un ambiente di sviluppo da un ambiente di produzione. Per informazioni di alto livello sulla creazione di un ruolo che consenta agli utenti nell'account di sviluppo di accedere alle risorse nell'account di produzione, consulta la sezione [Esempio di uno scenario in cui si utilizzano account di sviluppo e produzione separati](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example).
**Creare un ruolo utilizzando una policy di attendibilità personalizzata (console)**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel riquadro di navigazione della console, selezionare **Ruoli** e **Crea ruolo**.
1. Scegli il tipo di ruolo **Custom trust policy** (Policy di attendibilità personalizzata).
1. Nella sezione **Custom trust policy** (Policy di attendibilità personalizzata), inserisci o incolla la policy di attendibilità personalizzata per il ruolo. Per ulteriori informazioni, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start).
1. Risolvi eventuali avvisi di sicurezza, errori o avvisi generali generati durante la [convalida delle policy](access_policies_policy-validator.md), quindi scegli **Next** (Successivo).
1. (Facoltativo) Impostare un [limite delle autorizzazioni](access_policies_boundaries.md). Questa è una funzionalità avanzata disponibile per i ruoli di servizio, ma non per i ruoli collegati ai servizi.
Apri la sezione **Permissions boundary** (Limite delle autorizzazioni) e scegli **Use a permissions boundary to control the maximum role permissions** (Usa un limite delle autorizzazioni per controllare il numero massimo di autorizzazioni del ruolo). IAM include un elenco delle politiche AWS gestite e gestite dai clienti nel tuo account. Selezionare la policy da utilizzare per il limite delle autorizzazioni.
1. Scegli **Next (Successivo)**.
1. Il grado di personalizzazione per **Nome ruolo** viene definito dal servizio. Se il servizio definisce il nome del ruolo, questa opzione non può essere modificata. In altri casi, il servizio può definire un prefisso per il ruolo e consentire all'utente di aggiungere un suffisso opzionale. Alcuni servizi consentono di specificare l'intero nome del ruolo.
Se possibile, inserisci un nome del ruolo o un suffisso del nome del ruolo. I nomi dei ruoli devono essere univoci all'interno del tuo Account AWS. Non si distinguono per caso. Ad esempio, non è possibile creare ruoli denominati sia **PRODROLE** che **prodrole**. Poiché altre AWS risorse potrebbero fare riferimento al ruolo, non è possibile modificare il nome del ruolo dopo che è stato creato.
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per il nuovo ruolo.
1. (Facoltativo) Scegli **Modifica** nelle sezioni **Fase 1: seleziona le entità attendibili** o **Fase 2: aggiungi autorizzazioni** per modificare la policy personalizzata e le autorizzazioni per il ruolo.
1. (Facoltativo) Aggiungere 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. Rivedere il ruolo e scegliere **Crea ruolo**.
# Esempi di policy per la delega dell'accesso
Gli esempi seguenti mostrano come consentire o concedere Account AWS l'accesso alle risorse di un altro Account AWS. Per ulteriori informazioni su come creare una policy IAM utilizzando questi documenti di policy JSON, consulta [Creazione di policy utilizzando l'editor JSON](access_policies_create-console.md#access_policies_create-json-editor).
**Topics**
+ [Utilizzo dei ruoli per delegare l'accesso alle risorse di altre Account AWS risorse](#example-delegate-xaccount-rolesapi)
+ [Utilizzo di una policy per delegare l'accesso ai servizi](#id_roles_create_policy-examples-access-to-services)
+ [Utilizzo di una policy basata sulle risorse per delegare l'accesso a un bucket Amazon S3 in un altro account](#example-delegate-xaccount-S3)
+ [Utilizzo di una policy basata sulle risorse per delegare l'accesso a una coda Amazon SQS in un altro account](#example-delegate-xaccount-SQS)
+ [Impossibile delegare l'accesso quando l'accesso all'account è rifiutato](#example-delegate-xaccount-SQS-denied)
## Utilizzo dei ruoli per delegare l'accesso alle risorse di altre Account AWS risorse
Per un tutorial che mostra come utilizzare i ruoli IAM per concedere agli utenti di un account l'accesso alle AWS risorse presenti in un altro account, consulta[Tutorial IAM: delega l'accesso tra AWS account utilizzando i ruoli IAM](tutorial_cross-account-with-roles.md).
**Importante**
È possibile includere l'ARN per un ruolo o utente specifico nell'elemento `Principal` di una policy di affidabilità del ruolo. Quando si salva la policy, AWS trasforma l'ARN in un ID principale univoco. Ciò aiuta a mitigare il rischio che qualcuno aumenti i propri privilegi rimuovendo e ricreando il ruolo o l'utente. Questa ID nella console non è normalmente presente, in quanto c'è anche una trasformazione inversa verso il nome ARN quando la policy di affidabilità viene visualizzata. Tuttavia, se si elimina il ruolo o l'utente, la relazione viene interrotta. La policy non è più applicabile, anche se si ricrea l'utente o il ruolo perché non corrisponde all'ID principale archiviato nella policy di attendibilità. Quando ciò accade, l'ID principale viene visualizzato nella console perché non è più AWS possibile mapparlo su un ARN. Il risultato è che se si elimina e si ricrea un utente o un ruolo referenziato in un elemento `Principal` della policy di attendibilità, è necessario modificare il ruolo per sostituire il nome ARN. L'utente o il ruolo viene trasformato nel nuovo ID principale quando si salva la policy.
## Utilizzo di una policy per delegare l'accesso ai servizi
L'esempio seguente mostra una policy che può essere collegata a un ruolo. La policy consente a due servizi, Amazon EMR e AWS Data Pipeline, di assumere il ruolo. I servizi possono eseguire qualsiasi attività concesse da una policy di autorizzazioni assegnata al ruolo (non visualizzato). Per specificare più principali del servizio, non si specificano due elementi `Service`, è possibile averne solo uno. Utilizzare invece una serie di principali del servizio come il valore di un elemento singolo `Service`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"elasticmapreduce.amazonaws.com",
"datapipeline.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
## Utilizzo di una policy basata sulle risorse per delegare l'accesso a un bucket Amazon S3 in un altro account
In questo esempio, l'account A utilizza una policy basata sulle risorse (una [policy del bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html) Amazon S3) per concedere all'account B l'accesso completo al bucket S3 dell'account A. A questo punto, l'account B crea una policy utente IAM per delegare tale accesso al bucket dell'account A a uno degli utenti nell'account B.
La policy del bucket S3 nell'account A potrebbe essere simile alla policy seguente. In questo esempio, il bucket S3 dell'account A è denominato *amzn-s3-demo-bucket* e il numero dell'account B è 111122223333. Non specifica alcun utente o gruppo nell'account B, ma solo l'account stesso.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AccountBAccess1",
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
In alternativa, l'account A può utilizzare Amazon S3 [Access Control Lists (ACLs)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html) per concedere all'account B l'accesso a un bucket S3 o a un singolo oggetto all'interno di un bucket. In questo caso, l'unica cosa che cambia è il modo in cui l'account A concede l'accesso all'account B. L'account B utilizza ancora una policy per delegare l'accesso a un gruppo IAM nell'account B, come descritto nella parte successiva di questo esempio. Per maggiori informazioni sul controllo dell'accesso a bucket e oggetti S3, passa a [Controllo accessi](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
L'amministratore dell'account B potrebbe creare le seguenti policy di esempio. La policy permette l'accesso in lettura a un gruppo o un utente nell'account B. La policy precedente concede l'accesso all'account B. Tuttavia, i singoli gruppi e gli utenti dell'account B non possono accedere alla risorsa finché una policy utente o di gruppo non concede esplicitamente le autorizzazioni alla risorsa. Le autorizzazioni in questa policy possono essere solo un subset di quelli nella precedente policy multiaccount. L'account B non può concedere più autorizzazioni ai propri gruppi e utenti rispetto a quanti concessi dall'account A all'account B nella prima policy. In questa policy, l'elemento `Action` è esplicitamente definito per permettere solo operazioni `List` e l'elemento `Resource` di questa policy corrisponde all'elemento `Resource` per la policy del bucket implementata dall'account A.
Per implementare questa policy, l'account B utilizza IAM per collegarla all'utente (o al gruppo) appropriato nell'account B.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:List*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
## Utilizzo di una policy basata sulle risorse per delegare l'accesso a una coda Amazon SQS in un altro account
Nell'esempio seguente, l'account A ha una coda Amazon SQS che utilizza una policy basata sulla risorsa collegata alla coda per concedere l'accesso in coda all'account B. Quindi, l'account B utilizza una policy di gruppo IAM per delegare l'accesso a un gruppo nell'account B.
La seguente policy di coda di esempio fornisce all'account B l'autorizzazione per eseguire le operazioni `SendMessage` e `ReceiveMessage` sulla coda dell'account A denominata *queue1*, ma solo tra mezzogiorno e le 15:00 del 30 novembre 2014. Il numero dell'account B è 1111-2222-3333. L'account A usa Amazon SQS per implementare questa policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": ["arn:aws:sqs:*:123456789012:queue1"],
"Condition": {
"DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
"DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
}
}
}
```
------
La policy dell'account B per la delega dell'accesso a un gruppo nell'account B potrebbe essere simile all'esempio seguente. L'account B usa IAM per collegare questa policy a un gruppo (o utente).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:123456789012:queue1"
}
}
```
------
Nell'esempio della policy utente IAM precedente, l'account B utilizza un carattere jolly per concedere all'utente l'accesso a tutte le operazioni Amazon SQS per la coda dell'account A. Tuttavia, l'account B può delegare l'accesso solo nella misura in cui all'account B è stato concesso l'accesso. Il gruppo dell'account B con la seconda policy può accedere alla coda solo tra mezzogiorno e le 15:00 del 30 novembre 2014. L'utente può eseguire solo le operazioni `SendMessage` e `ReceiveMessage`, come definito nella policy della coda Amazon SQS dell'account A.
## Impossibile delegare l'accesso quando l'accesso all'account è rifiutato
Un Account AWS non può delegare l'accesso alle risorse di un altro account se l'altro account ha negato esplicitamente l'accesso all'account principale dell'utente. Il rifiuto si propaga agli utenti di tale account indipendentemente dal fatto che gli utenti dispongano di policy esistenti che garantiscono loro l'accesso.
Ad esempio, l'account A scrive una policy bucket per il bucket S3 dell'account A che rifiuta esplicitamente l'accesso all'account B per il bucket dell'account A. Tuttavia, l'account B scrive una policy utente IAM che concede a un utente dell'account B l'accesso al bucket dell'account A. Il rifiuto esplicito applicato al bucket S3 dell'account A si propaga agli utenti dell'account B e sostituisce la policy dell'utente IAM che concede l'accesso all'utente dell'account B. Per informazioni dettagliate su come vengono valutate le autorizzazioni, consulta [Logica di valutazione delle policy](reference_policies_evaluation-logic.md).
La policy del bucket dell'account A potrebbe essere simile alla policy seguente. In questo esempio, il bucket S3 dell'account A è denominato *amzn-s3-demo-bucket* e il numero dell'account B è 1111-2222-3333. L'account A usa Amazon S3 per implementare questa policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AccountBDeny",
"Effect": "Deny",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
}
```
------
Questo rifiuto esplicito sostituisce qualsiasi policy dell'account B che fornisce l'autorizzazione per accedere al bucket S3 nell'account A.