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à.
# Autorizzazioni per le credenziali di sicurezza temporanee
Puoi usare AWS Security Token Service (AWS STS) per creare e fornire a utenti affidabili credenziali di sicurezza temporanee in grado di controllare l'accesso alle tue AWS risorse. Per ulteriori informazioni su AWS STS, vedere[Credenziali di sicurezza temporanee in IAM](id_credentials_temp.md). Le credenziali di sicurezza temporanee emesse da AWS STS sono valide fino al periodo di scadenza e non possono essere revocate. Tuttavia, le autorizzazioni assegnate a tali credenziali vengono valutate ogni volta che viene effettuata una richiesta che utilizza le credenziali stesse, pertanto è possibile ottenere l'effetto di revoca delle credenziali modificando i relativi diritti di accesso dopo che sono state emesse.
Negli argomenti seguenti si presuppone che tu abbia una conoscenza pratica delle AWS autorizzazioni e delle politiche. Per ulteriori informazioni su questi argomenti, consultare [Gestione degli accessi AWS alle risorse](access.md).
**Topics**
+ [Autorizzazioni per AssumeRole, AssumeRoleWith SAML e AssumeRoleWithWebIdentity](id_credentials_temp_control-access_assumerole.md)
+ [Monitoraggio e controllo delle operazioni intraprese con i ruoli assunti](id_credentials_temp_control-access_monitor.md)
+ [Autorizzazioni per GetFederationToken](id_credentials_temp_control-access_getfederationtoken.md)
+ [Autorizzazioni per GetSessionToken](id_credentials_temp_control-access_getsessiontoken.md)
+ [Disabilitazione delle autorizzazioni per le credenziali di sicurezza temporanee](id_credentials_temp_control-access_disable-perms.md)
+ [Concessione delle autorizzazioni per creare credenziali di sicurezza temporanee](id_credentials_temp_control-access_enable-create.md)
+ [Concessione delle autorizzazioni per l’utilizzo di sessioni di console rafforzate con l’identità](id_credentials_temp_control-access_sts-setcontext.md)
# Autorizzazioni per AssumeRole, AssumeRoleWith SAML e AssumeRoleWithWebIdentity
La policy di autorizzazione del ruolo assunto determina le autorizzazioni per le credenziali di sicurezza temporanee restituite da `AssumeRole`, `AssumeRoleWithSAML` e `AssumeRoleWithWebIdentity`. Puoi definire queste autorizzazioni quando crei o aggiorni il ruolo.
Facoltativamente, puoi trasferire le [policy di sessione](access_policies.md#policies_session) inline o gestite come parametri delle operazioni API `AssumeRole`, `AssumeRoleWithSAML` o `AssumeRoleWithWebIdentity`. Le policy di sessione limitano le autorizzazioni per la sessione con credenziali temporanee del ruolo. Le autorizzazioni della sessione risultante sono l'intersezione della policy basata sull'identità del ruolo e delle policy di sessione. Puoi utilizzare le credenziali temporanee del ruolo nelle successive chiamate AWS API per accedere alle risorse dell'account proprietario del ruolo. Non puoi utilizzare policy di sessione per concedere autorizzazioni maggiori rispetto a quelle consentite dalla policy basata su identità del ruolo che viene assunto. Per ulteriori informazioni su come AWS determina le autorizzazioni valide di un ruolo, consulta [Logica di valutazione delle policy](reference_policies_evaluation-logic.md).
![\[PermissionsWhenPassingRoles_Diagramma\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)
Le politiche allegate alle credenziali a cui è stata effettuata la chiamata originale non `AssumeRole` vengono valutate AWS quando si prende la decisione di autorizzazione «consentire» o «negare». L'utente rinuncia temporaneamente alle autorizzazioni originali a favore delle autorizzazioni assegnate dal ruolo assunto. Nel caso delle operazioni `AssumeRoleWithSAML` e dell'`AssumeRoleWithWebIdentity`API, non ci sono policy da valutare perché il chiamante dell'API non è un'identità. AWS
## Esempio: assegnazione di autorizzazioni utilizzando AssumeRole
È possibile usare l'operazione API `AssumeRole` con diversi tipi di policy. Di seguito sono illustrati alcuni esempi.
### Policy di autorizzazione di un ruolo
In questo esempio chiami l'operazione API `AssumeRole` senza specificare la policy di sessione nel parametro `Policy` facoltativo. Le autorizzazioni assegnate alle credenziali temporanee sono determinate dalla policy di autorizzazione del ruolo assunto. La policy di autorizzazioni di esempio seguente concede al ruolo l'autorizzazione per elencare tutti gli oggetti contenuti in un bucket S3 denominato `productionapp`. Consente inoltre al ruolo di ottenere, inserire ed eliminare gli oggetti all'interno del bucket.
**Example Policy di autorizzazione di un ruolo di esempio**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### Policy di sessione passata come parametro
Immaginiamo di voler consentire a un utente di assumere lo stesso ruolo dell'esempio precedente. In questo caso però il ruolo della sessione deve avere l'autorizzazione solo per ottenere e mettere oggetti nel bucket S3 `productionapp`. Non desideri permettere all'utente di eliminare gli oggetti. Un metodo per raggiungere questo scopo consiste nel creare un nuovo ruolo e specificare le autorizzazioni desiderate nella policy di autorizzazione di tale ruolo. Un altro metodo per raggiungere lo scopo consiste nel chiamare l'API `AssumeRole` e includere una policy di sessione nel parametro `Policy` facoltativo come parte dell'operazione API. Le autorizzazioni della sessione risultanti sono l'intersezione tra le policy basate sull'identità del ruolo e le policy di sessione. Le policy di sessione non possono essere utilizzate per concedere autorizzazioni maggiori rispetto a quelle consentite dalla policy basata sull'identità del ruolo che viene assunto. Per ulteriori informazioni sulle autorizzazioni della sessione del ruolo, consulta [Policy di sessione](access_policies.md#policies_session).
Dopo aver recuperato le credenziali temporanee della nuova sessione, puoi passarle all'utente che deve disporre di tali autorizzazioni.
Immagina, ad esempio, che la policy seguente venga passata come parametro della chiamata API. L'utente che utilizza la sessione dispone di autorizzazioni per eseguire solo le seguenti azioni:
+ Elencare tutti gli oggetti nel bucket `productionapp`.
+ Ottenere e inserire gli oggetti nel bucket `productionapp`.
Nella policy di sessione seguente, l'autorizzazione `s3:DeleteObject` viene esclusa e alla sessione assunta non viene concessa l'autorizzazione `s3:DeleteObject`. La policy imposta il numero massimo di autorizzazioni per la sessione del ruolo, in modo che sostituisca qualsiasi policy di autorizzazione esistente su quel ruolo.
**Example Esempio di policy di sessione passata con la chiamata API `AssumeRole`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### Politica basata sulle risorse
Alcune AWS risorse supportano politiche basate sulle risorse e queste politiche forniscono un altro meccanismo per definire le autorizzazioni che influiscono sulle credenziali di sicurezza temporanee. Solo alcune risorse, come i bucket Amazon S3, gli argomenti Amazon SNS e le code Amazon SQS, supportano le policy basate sulle risorse. L'esempio seguente fornisce ulteriori informazioni sugli esempi precedenti, utilizzando un bucket S3, denominato `productionapp`. La policy seguente è collegata al bucket.
Quando colleghi la seguente policy basata su risorse al bucket `productionapp`, a *tutti* gli utenti viene negata l'autorizzazione per eliminare gli oggetti dal bucket. (Consulta l'elemento `Principal` nella policy). Ciò include tutti gli utenti che assumono il ruolo, anche se la policy di autorizzazione del ruolo concede l'autorizzazione `DeleteObject`. Un'istruzione `Deny` esplicita ha sempre la precedenza su un'istruzione `Allow`.
**Example Esempio di policy di bucket**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {"AWS": "*"},
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::productionapp/*"
}
}
```
Per ulteriori informazioni su come più tipi di policy vengono combinati e valutati da. AWS[Logica di valutazione delle policy](reference_policies_evaluation-logic.md)
# Monitoraggio e controllo delle operazioni intraprese con i ruoli assunti
Un [ruolo IAM](id_roles.md) è un oggetto in IAM a cui sono assegnate delle [autorizzazioni](access_policies.md). Quando [assumi quel ruolo](id_roles_manage-assume.md) utilizzando un'identità IAM o un'identità esterna AWS, ricevi una sessione con le autorizzazioni assegnate al ruolo.
Quando esegui azioni in AWS, le informazioni sulla sessione possono essere registrate AWS CloudTrail per essere monitorate dall'amministratore dell'account. Gli amministratori possono configurare i ruoli in modo da richiedere alle identità di inviare una stringa personalizzata che identifichi la persona o l'applicazione che esegue operazioni in AWS. Queste informazioni di identità vengono archiviate come *identità di origine* in AWS CloudTrail. Quando l'amministratore esamina l'attività in CloudTrail, può visualizzare le informazioni sull'identità di origine per determinare chi o cosa ha eseguito le azioni nelle sessioni di ruolo assunte.
Una volta impostata, l'identità di origine è presente nelle richieste di qualsiasi AWS azione intrapresa durante la sessione di ruolo. Il valore impostato persiste quando un ruolo viene utilizzato per assumere un altro ruolo tramite l' AWS API AWS CLI o, nota come [concatenamento dei ruoli](id_roles.md#iam-term-role-chaining). Il valore impostato non può essere modificato durante la sessione del ruolo. Gli amministratori possono configurare autorizzazioni granulari in base alla presenza o al valore dell'identità di origine per controllare ulteriormente AWS le azioni intraprese con ruoli condivisi. È possibile decidere se l'attributo dell'identità di origine può essere utilizzato, se è obbligatorio e quale valore può essere utilizzato.
Il modo in cui si utilizza l'identità di origine differisce dal nome della sessione di ruolo e dai tag di sessione in modo importante. Il valore dell'identità di origine non può essere modificato dopo l'impostazione e persiste per eventuali operazioni aggiuntive eseguite con la sessione del ruolo. Ecco come utilizzare i tag di sessione e il nome della sessione del ruolo:
+ **Tag di sessione**: puoi passare i tag di sessione quando assumi un ruolo o federi un utente. I tag di sessione sono presenti quando si assume un ruolo. È possibile definire policy che utilizzano le chiavi condizionali sui tag per concedere autorizzazioni ai principali sulla base dei relativi tag. Quindi puoi utilizzarle CloudTrail per visualizzare le richieste fatte per assumere ruoli o federare gli utenti. Per ulteriori informazioni sui tag di sessione, consulta [Passa i tag di sessione AWS STS](id_session-tags.md).
+ **Nome sessione del ruolo**: puoi utilizzare la chiave di condizione `sts:RoleSessionName` in una policy di attendibilità del ruolo per richiedere che gli utenti forniscano un nome di sessione specifico quando assumono un ruolo. Il nome della sessione del ruolo può essere utilizzato per distinguere le sessioni del ruolo quando un ruolo viene utilizzato da principali diversi. Per saperne di più sul nome della sessione di ruolo, vedi [sts: RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname).
Si consiglia di utilizzare l'identità di origine quando si desidera controllare l'identità che assume un ruolo. L'identità di origine è utile anche per CloudTrail i log di mining per determinare chi ha utilizzato il ruolo per eseguire azioni.
**Topics**
+ [Configurazione per l'uso dell'identità di origine](#id_credentials_temp_control-access_monitor-setup)
+ [Cose da sapere sull'identità di origine](#id_credentials_temp_control-access_monitor-know)
+ [Autorizzazioni necessarie per impostare l'identità di origine](#id_credentials_temp_control-access_monitor-perms)
+ [Specifica di un'identità di origine quando si assume un ruolo](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [Utilizzo dell'identità di origine con AssumeRole](#id_credentials_temp_control-access_monitor-assume-role)
+ [Utilizzo dell'identità di origine con SAML AssumeRoleWith](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [Utilizzo dell'identità di origine con AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [Controllo dell'accesso tramite le informazioni sull'identità di origine](#id_credentials_temp_control-access_monitor-control-access)
+ [Visualizzazione dell'identità di origine in CloudTrail](#id_credentials_temp_control-access_monitor-ct)
## Configurazione per l'uso dell'identità di origine
Il modo in cui si imposta l'utilizzo dell'identità di origine dipende dal metodo utilizzato quando si assumono i ruoli. Ad esempio, gli utenti IAM potrebbero assumere ruoli direttamente utilizzando l'operazione `AssumeRole`. Se disponi di identità aziendali, note anche come identità della forza lavoro, queste potrebbero accedere alle tue risorse utilizzando. AWS `AssumeRoleWithSAML` Se gli utenti finali accedono alle tue applicazioni per dispositivi mobile o Web, potrebbero farlo utilizzando `AssumeRoleWithWebIdentity`. Di seguito è riportata una panoramica di alto livello del flusso di lavoro che consente di comprendere come impostare l'utilizzo delle informazioni sull'identità di origine nell'ambiente esistente.
1. **Configurazione di utenti e ruoli di test**: in un ambiente di preproduzione, configura utenti e ruoli di prova e configura le relative policy per consentire l'impostazione di un'identità di origine.
Se utilizzi un provider di identità (IdP) per le identità federate, configura l'IdP per inviare un attributo utente a scelta per l'identità di origine nell'asserzione o nel token.
1. **Assunzione del ruolo**: verifica l'assunzione di ruoli e l'invio di un'identità di origine con gli utenti e i ruoli impostati per il test.
1. **Revisione CloudTrail**: rivedi le informazioni sull'identità di origine per i ruoli di test nei tuoi registri. CloudTrail
1. **Formazione degli utenti**: dopo aver eseguito il test nell'ambiente di preproduzione, assicurati che gli utenti sappiano come inviare le informazioni sull'identità di origine, se necessario. Imposta una scadenza per il momento in cui sarà richiesto agli utenti di fornire un'identità di origine nell'ambiente di produzione.
1. **Configurazione delle policy di produzione**: configura le policy per l'ambiente di produzione e quindi aggiungile agli utenti e ai ruoli di produzione.
1. **Monitora l'attività**: monitora l'attività del ruolo di produzione utilizzando i CloudTrail log.
## Cose da sapere sull'identità di origine
Quando si utilizza un'identità di origine, tieni presente quanto segue.
+ Le policy di attendibilità per tutti i ruoli connessi a un provider di identità (IdP) devono disporre dell'autorizzazione `sts:SetSourceIdentity`. Per i ruoli che non dispongono di questa autorizzazione nella policy di attendibilità, l'operazione `AssumeRole*` avrà esito negativo. Se non desideri aggiornare la policy di attendibilità del ruolo per ogni ruolo, puoi utilizzare un'istanza IdP separata per passare l'identità di origine. Quindi, aggiungere l'autorizzazione `sts:SetSourceIdentity` solo ai ruoli connessi all'IdP separato.
+ Quando un'identità imposta un'identità di origine, la chiave `sts:SourceIdentity` è presente nella richiesta. Per le azioni successive intraprese durante la sessione di ruolo, la chiave `aws:SourceIdentity` è presente nella richiesta. AWS non controlla il valore dell'identità di origine nelle chiavi `sts:SourceIdentity` o `aws:SourceIdentity`. Se decidi di richiedere un'identità di origine, è necessario scegliere un attributo che sia fornito dagli utenti o dall'IdP. Per motivi di sicurezza, è necessario assicurarsi di poter controllare il modo in cui tali valori vengono forniti.
+ Il valore dell'identità di origine deve contenere tra 2 e 64 caratteri, può contenere solo caratteri alfanumerici, caratteri di sottolineatura e i seguenti caratteri: **. , \$1 = @ -** (trattino). Non è possibile utilizzare un valore che inizia con il testo **aws:**. Questo prefisso è riservato all'uso AWS interno.
+ Le informazioni sull'identità di origine non vengono acquisite CloudTrail quando un AWS servizio o un ruolo collegato al servizio esegue un'azione per conto di un'identità federata o della forza lavoro.
**Importante**
Non è possibile passare a un ruolo Console di gestione AWS che richiede l'impostazione di un'identità di origine al momento dell'assunzione del ruolo. Per assumere un ruolo di questo tipo, è possibile utilizzare l' AWS API AWS CLI or per richiamare l'`AssumeRole`operazione e specificare il parametro source identity.
## Autorizzazioni necessarie per impostare l'identità di origine
Oltre a quella sull'operazione che corrisponde all'operazione API, è necessario disporre nella policy dell'autorizzazione per le seguenti operazioni:
```
sts:SetSourceIdentity
```
+ Per specificare un'identità di origine, i principali (utenti e ruoli IAM) devono disporre delle autorizzazioni per`sts:SetSourceIdentity`. In qualità di amministratore, puoi configurarlo nella policy di attendibilità del ruolo e nella policy di autorizzazione del principale.
+ Quando si assume un ruolo con un altro ruolo, secondo la funzione denominata [concatenamento dei ruoli](id_roles.md#iam-term-role-chaining), le autorizzazioni per `sts:SetSourceIdentity` sono necessarie sia nella policy di autorizzazione del principale che assume il ruolo sia nella policy di attendibilità del ruolo del ruolo di destinazione. In caso contrario, l'operazione di assunzione del ruolo avrà esito negativo.
+ Quando si utilizza l'identità di origine, le policy di attendibilità dei ruoli per tutti i ruoli connessi a un provider di identità (IdP) devono disporre dell'autorizzazione `sts:SetSourceIdentity`. L'operazione `AssumeRole*` avrà esito negativo per qualsiasi ruolo connesso a un IdP senza questa autorizzazione. Se non desideri aggiornare la policy di attendibilità del ruolo per ogni ruolo, puoi utilizzare un'istanza IdP separata per inviare l'identità di origine e aggiungere l'autorizzazione `sts:SetSourceIdentity` solo ai ruoli connessi all'IdP separato.
+ Per impostare un'identità di origine oltre i limiti dell'account, è necessario includere l'autorizzazione `sts:SetSourceIdentity` in due posti. Deve trovarsi nella policy di autorizzazione del principale nell'account di origine e nella policy di attendibilità del ruolo del ruolo nell'account di destinazione. Questa operazione potrebbe essere necessaria, ad esempio, quando un ruolo viene utilizzato per assumere un ruolo in un altro account con il [concatenamento dei ruoli](id_roles.md#iam-term-role-chaining).
Come amministratore dell'account, immagina di voler consentire all'utente IAM `DevUser` nel tuo account per assumere il `Developer_Role` nello stesso account. Tuttavia, si desidera consentire questa operazione solo se l'utente ha impostato l'identità di origine sul proprio nome utente IAM. La seguente policy può essere collegata a un utente IAM.
**Example Esempio di politica basata sull'identità allegata a DevUser**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role"
},
{
"Sid": "SetAwsUserNameAsSourceIdentity",
"Effect": "Allow",
"Action": "sts:SetSourceIdentity",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role",
"Condition": {
"StringLike": {
"sts:SourceIdentity": "${aws:username}"
}
}
}
]
}
```
Per applicare i valori di identità di origine accettabili, è possibile configurare la policy di attendibilità del ruolo riportata di seguito. La policy fornisce all'utente IAM le autorizzazioni `DevUser`per assumere il ruolo e impostare un'identità di origine. La chiave di condizione `sts:SourceIdentity` definisce il valore di identità di origine accettabile.
**Example Esempio di policy di attendibilità dei ruoli dell'identità di origine**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDevUserAssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/DevUser"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"sts:SourceIdentity": "DevUser"
}
}
}
]
}
```
------
Utilizzando le credenziali per l'utente IAM`DevUser`, l'utente tenta di presumere l'`DeveloperRole`utilizzo della seguente richiesta. AWS CLI
**Example Richiesta AssumeRole CLI di esempio**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \
--source-identity DevUser \
```
Quando AWS valuta la richiesta, il contesto della richiesta contiene il `sts:SourceIdentity` comando di. `DevUser`
## Specifica di un'identità di origine quando si assume un ruolo
È possibile specificare un'identità di origine quando si utilizza una delle operazioni AWS STS `AssumeRole*` API per ottenere credenziali di sicurezza temporanee per un ruolo. L'operazione API che usi è diversa a seconda del caso d'uso. Ad esempio, se utilizzi i ruoli IAM per consentire agli utenti IAM di accedere a AWS risorse a cui normalmente non hanno accesso, potresti utilizzare l'`AssumeRole`operazione. Se utilizzi la federazione delle identità aziendali per gestire gli utenti della forza lavoro, puoi utilizzare l'operazione `AssumeRoleWithSAML`. Se utilizzi la federazione OIDC per consentire agli utenti finali di accedere alle applicazioni mobili o Web, puoi utilizzare l'operazione `AssumeRoleWithWebIdentity`. Nelle sezioni seguenti viene illustrato come utilizzare l'identità di origine per ogni operazione. Per ulteriori informazioni sugli scenari comuni per le credenziali temporanee, consulta [Scenari comuni per le credenziali temporanee](id_credentials_temp.md#sts-introduction).
## Utilizzo dell'identità di origine con AssumeRole
L'`AssumeRole`operazione restituisce un set di credenziali temporanee che è possibile utilizzare per accedere alle AWS risorse. È possibile utilizzare le credenziali dell'utente o del ruolo IAM per chiamare `AssumeRole`. Per passare l'identità di origine mentre assumi un ruolo, utilizzate l'`-–source-identity` AWS CLI opzione o il parametro `SourceIdentity` AWS API. L'esempio seguente illustra come specificare l'identità di origine utilizzando la AWS CLI.
**Example Richiesta AssumeRole CLI di esempio**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \
--source-identity Admin \
```
## Utilizzo dell'identità di origine con SAML AssumeRoleWith
Il principale che richiama l'operazione `AssumeRoleWithSAML` viene autenticato utilizzando la federazione basata su SAML. Questa operazione restituisce un set di credenziali temporanee che puoi utilizzare per accedere AWS alle risorse. Per ulteriori informazioni sull'utilizzo della federazione basata su SAML per Console di gestione AWS l'accesso, consulta. [Consentire ai principali federati SAML 2.0 di accedere a Console di gestione AWS](id_roles_providers_enable-console-saml.md) Per dettagli sull'accesso alle AWS CLI nostre AWS API, consulta. [Federazione SAML 2.0](id_roles_providers_saml.md) Per un tutorial sulla configurazione della federazione SAML per gli utenti di Active Directory, consulta [AWS Federated Authentication with Active Directory Federation Services (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) nel AWS Security Blog.
In qualità di amministratore, puoi consentire ai membri della tua directory aziendale di unirsi AWS per utilizzare l'operazione. AWS STS `AssumeRoleWithSAML` A tale scopo, è necessario completare le seguenti attività:
1. [Configura un provider SAML nella tua organizzazione](id_roles_providers_saml_3rd-party.md).
1. [Creazione di un provider SAML in IAM](id_roles_providers_create_saml.md).
1. [Configura un ruolo e le relative autorizzazioni AWS per i tuoi responsabili federati SAML.](id_roles_create_for-idp_saml.md)
1. [Fine della configurazione del provider di identità SAML e creazione di asserzioni per la risposta di autenticazione SAML](id_roles_providers_create_saml_assertions.md)
Per impostare un attributo SAML per l'identità di origine, includi l'elemento `Attribute` con l'attributo `Name` impostato su `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Utilizza l'elemento `AttributeValue` per specificare il valore dell'identità di origine. Ad esempio, si supponga di voler passare i seguenti attributi di identità come identità di origine:
`SourceIdentity:DiegoRamirez`
Per passare questi attributi, includi i seguenti elementi nell'asserzione SAML.
**Example Esempio di frammento di un'asserzione SAML**
```
DiegoRamirez
```
## Utilizzo dell'identità di origine con AssumeRoleWithWebIdentity
Il principale che richiama l'operazione `AssumeRoleWithWebIdentity` viene autenticato utilizzando la federazione compatibile con OpenID Connect (OIDC). Questa operazione restituisce un insieme di credenziali temporanee che è possibile utilizzare per accedere alle risorse di AWS . Per ulteriori informazioni sull'utilizzo della federazione OIDC per l'accesso alla Console di gestione AWS , consulta [Federazione OIDC](id_roles_providers_oidc.md).
Per passare l'identità di origine da OpenID Connect (OIDC), è necessario includere l'identità di origine nel Token Web JSON (JWT). Includi l’identità di origine nel namespace `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` nel token quando si invia la richiesta `AssumeRoleWithWebIdentity`. Per ulteriori informazioni sui token e le registrazioni OIDC, consultare [Utilizzo di token con pool di utenti](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) nella *Guida per gli sviluppatori Amazon Cognito *.
Ad esempio, il seguente JWT decodificato è un token utilizzato per chiamare `AssumeRoleWithWebIdentity` con l'identità di origine `Admin`.
**Example Esempio di token Web JSON decodificato**
```
{
"sub": "john",
"aud": "ac_oic_client",
"jti": "ZYUCeRMQVtqHypVPWAN3VB",
"iss": "https://xyz.com",
"iat": 1566583294,
"exp": 1566583354,
"auth_time": 1566583292,
"https://aws.amazon.com/source_identity":"Admin"
}
```
## Controllo dell'accesso tramite le informazioni sull'identità di origine
Quando viene inizialmente impostata un'identità di origine, la SourceIdentity chiave [sts:](reference_policies_iam-condition-keys.md#ck_sourceidentity) è presente nella richiesta. Dopo aver impostato un'identità di origine, la SourceIdentity chiave [aws:](reference_policies_condition-keys.md#condition-keys-sourceidentity) è presente in tutte le richieste successive effettuate durante la sessione di ruolo. In qualità di amministratore, puoi scrivere politiche che concedano l'autorizzazione condizionale per eseguire AWS azioni in base all'esistenza o al valore dell'attributo di identità di origine.
Immagina di voler richiedere ai tuoi sviluppatori di impostare un'identità di origine per assumere un ruolo fondamentale con il permesso di scrivere su una AWS risorsa fondamentale per la produzione. Immaginate inoltre di concedere AWS l'accesso alle identità della vostra forza lavoro utilizzando. `AssumeRoleWithSAML` Desideri solo che gli sviluppatori senior Saanvi e Diego abbiano accesso al ruolo, in modo che possano creare le seguenti policy di attendibilità per il ruolo.
**Example Esempio di policy di attendibilità dei ruoli dell'identità di origine (SAML)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SAMLProviderAssumeRoleWithSAML",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:AssumeRoleWithSAML"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
},
{
"Sid": "SetSourceIdentitySrEngs",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
La policy di attendibilità contiene una condizione per `sts:SourceIdentity` che richiede un'identità di origine impostata su Saanvi o Diego per assumere il ruolo critico.
In alternativa, se si utilizza un provider OIDC per la federazione e gli utenti sono autenticati con `AssumeRoleWithWebIdentity`, la tua policy di attendibilità del ruolo potrebbe avere un aspetto simile al seguente.
**Example Esempio di policy di attendibilità dei ruoli dell'identità di origine (provider OIDC)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"server.example.com:aud": "oidc-audience-id"
},
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
### Concatenamento dei ruoli e requisiti tra account
Immagina di voler consentire agli utenti che hanno assunto il ruolo `CriticalRole` di assumere un ruolo `CriticalRole_2` in un altro account. Le credenziali della sessione del ruolo ottenute per assumere `CriticalRole` sono utilizzate per il [concatenamento dei ruoli](id_roles.md#iam-term-role-chaining) per un secondo ruolo, `CriticalRole_2`, in un account diverso. Il ruolo viene assunto oltre un limite di account. Pertanto, l'autorizzazione `sts:SetSourceIdentity` deve essere concessa in entrambe le policy di autorizzazione su `CriticalRole` e nella policy di attendibilità del ruolo su `CriticalRole_2`.
**Example Esempio di politica di autorizzazione su CriticalRole**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleAndSetSourceIdentity",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
}
]
}
```
------
Per proteggere l'impostazione dell'identità di origine attraverso il limite dell'account, la seguente policy di attendibilità del ruolo considera attendibile solo il principale del ruolo per `CriticalRole` per impostare l'identità di origine.
**Example Esempio di politica di fiducia dei ruoli su \$12 CriticalRole**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CriticalRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"aws:SourceIdentity": ["Saanvi","Diego"]
}
}
}
]
}
```
------
L'utente effettua la chiamata seguente utilizzando le credenziali della sessione di ruolo ottenute da assumendo. CriticalRole L'identità di origine è stata impostata durante l'assunzione di CriticalRole, quindi non è necessario impostarla nuovamente in modo esplicito. Se l'utente prova a impostare un'identità di origine diversa dal set di valori quando è stato assunto `CriticalRole`, la richiesta di assumere il ruolo verrà rifiutata.
**Example Richiesta AssumeRole CLI di esempio**
```
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```
Quando il principale chiamante assume il ruolo, l'identità di origine nella richiesta persiste dalla prima sessione del ruolo assunto. Pertanto, entrambe le chiavi `aws:SourceIdentity` e `sts:SourceIdentity` sono presenti nel contesto della richiesta.
## Visualizzazione dell'identità di origine in CloudTrail
È possibile utilizzare CloudTrail per visualizzare le richieste fatte per assumere ruoli o federare gli utenti. È inoltre possibile visualizzare le richieste di ruoli o utenti per eseguire operazioni in AWS. Il file di CloudTrail registro include informazioni sull'identità di origine impostata per il ruolo assunto o la sessione utente federata. Per ulteriori informazioni, consulta [Registrazione delle chiamate IAM e AWS STS API con AWS CloudTrail](cloudtrail-integration.md)
Ad esempio, supponiamo che un utente effettui una AWS STS `AssumeRole` richiesta e imposti un'identità di origine. Puoi trovare le `sourceIdentity` informazioni nella `requestParameters` chiave del tuo CloudTrail registro.
**Example Esempio di sezione RequestParameters in un registro AWS CloudTrail**
```
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSAccount",
"principalId": "AIDAJ45Q7YFFAREXAMPLE",
"accountId": "111122223333"
},
"eventTime": "2020-04-02T18:20:53Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.64",
"userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
"requestParameters": {
"roleArn": "arn:aws:iam::123456789012:role/DevRole",
"roleSessionName": "Dev1",
"sourceIdentity": "source-identity-value-set"
}
```
Se l'utente utilizza la sessione di ruolo presunta per eseguire un'azione, le informazioni sull'identità di origine sono presenti nella `userIdentity` chiave del CloudTrail registro.
**Example Esempio di chiave UserIdentity in un registro AWS CloudTrail**
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
"arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAJ45Q7YFFAREXAMPLE",
"arn": "arn:aws:iam::123456789012:role/DevRole",
"accountId": "123456789012",
"userName": "DevRole"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-21T23:46:28Z"
},
"sourceIdentity": "source-identity-value-present"
}
}
}
```
Per vedere esempi di eventi AWS STS API nei CloudTrail log, consulta. [Esempi di eventi dell'API IAM nel registro CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api) Per maggiori dettagli sulle informazioni contenute nei file di CloudTrail registro, consulta [CloudTrail Event Reference](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) nella *Guida per l'AWS CloudTrail utente*.
# Autorizzazioni per GetFederationToken
L'operazione `GetFederationToken` viene chiamata da un utente IAM e restituisce le credenziali temporanee per tale utente. Questa operazione *consolida* l'utente. Le autorizzazioni assegnate a una sessione utente AWS STS federata sono definite in una delle due posizioni seguenti:
+ Le policy di sessione passate come un parametro della chiamata API `GetFederationToken`. (Questo è più comune).
+ Una politica basata sulle risorse che nomina esplicitamente la sessione utente AWS STS federata nell'elemento della politica. `Principal` (Questo è meno comune).
Le policy di sessione sono policy avanzate che vengono passate come parametri quando si crea una sessione temporanea a livello di programma. Quando si crea una sessione utente AWS STS federata e si passano i criteri di sessione, le autorizzazioni della sessione risultanti sono l'intersezione tra la politica basata sull'identità dell'utente e le politiche di sessione. Non puoi utilizzare la policy di sessione per concedere autorizzazioni maggiori rispetto a quelle consentite dalla policy basata su identità dell'utente che viene federato.
Nella maggior parte dei casi, se non si passa una policy con la chiamata API `GetFederationToken`, le credenziali di sicurezza temporanee risultanti non dispongono di autorizzazioni. Tuttavia, una policy basata sulle risorse è in grado di fornire ulteriori autorizzazioni per la sessione. Puoi accedere a una risorsa con una policy basata sulle risorse che specifica la sessione come l'entità principale consentita.
Le seguenti immagini mostrano una rappresentazione visiva di come le policy interagiscono per determinare le autorizzazioni per le credenziali di sicurezza provvisorie restituite da una chiamata a `GetFederationToken`.
![\[Utente IAM Le seguenti illustrazioni mostrano i segni di spunta per indicare che le autorizzazioni di sessione sono l'intersezione della policy basata sull'identità dell'utente e le policy di sessione. Le autorizzazioni di sessione possono inoltre essere l'intersezione delle policy basate sulle identità e delle policy basate sulle risorse dell'utente.\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## Esempio: assegnazione di autorizzazioni tramite GetFederationToken
È possibile utilizzare l'operazione API `GetFederationToken` con diversi tipi di policy. Di seguito sono illustrati alcuni esempi.
### Policy collegata all'utente IAM
In questo esempio, disponi di un'applicazione client basata sul browser che si avvale di due servizi Web di backend. Un servizio di backend è il tuo server di autenticazione che utilizza un sistema di identità per autenticare l'applicazione client. L'altro servizio di backend è un servizio AWS che fornisce alcune delle funzionalità dell'applicazione client. L'applicazione client viene autenticata mediante il tuo server, il quale crea o recupera la policy di autorizzazione appropriata. Il server chiama l'API `GetFederationToken` per ottenere le credenziali di sicurezza provvisorie e restituisce tali credenziali all'applicazione client. L'applicazione client può quindi effettuare richieste direttamente al AWS servizio con le credenziali di sicurezza temporanee. Questa architettura consente all'applicazione client di effettuare AWS richieste senza incorporare credenziali a lungo termine AWS .
Il tuo server di autenticazione chiama l'API `GetFederationToken` con le credenziali di sicurezza a lungo termine di un utente IAM denominato `token-app`. Tuttavia, le credenziali utente IAM a lungo termine rimangono nel server e non vengono mai distribuite al client. La seguente policy di esempio è allegata all'utente `token-app` IAM e definisce il set più ampio di autorizzazioni di cui avranno bisogno gli utenti AWS STS federati (client). Tieni presente che l'`sts:GetFederationToken`autorizzazione è necessaria affinché il servizio di autenticazione ottenga credenziali di sicurezza temporanee per gli utenti federati. AWS STS
**Example Esempio di policy collegata all'utente IAM `token-app` che chiama `GetFederationToken`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "dynamodb:ListTables",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:ReceiveMessage",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:ListSubscriptions",
"Resource": "*"
}
]
}
```
La policy precedente concede diverse autorizzazioni all'utente IAM. Tuttavia, questa politica da sola non concede alcuna autorizzazione all'utente federato AWS STS . Se questo utente IAM chiama `GetFederationToken` e non passa una policy come parametro della chiamata API, l'utente AWS STS federato risultante non dispone di autorizzazioni valide.
### Policy di sessione passata come parametro
Il modo più comune per garantire che all'utente AWS STS federato venga assegnata l'autorizzazione appropriata consiste nel trasmettere le politiche di sessione nella `GetFederationToken` chiamata API. Sulla base dell'esempio precedente, immagina che `GetFederationToken` venga chiamato con le credenziali dell'utente IAM `token-app`. Quindi, immagina che la policy di sessione seguente venga passata come un parametro della chiamata API. L’utente federato AWS STS risultante dispone dell’autorizzazione per elencare i contenuti del bucket Amazon S3 denominato `productionapp`. L'utente non può eseguire le operazioni `GetObject`, `PutObject` e `DeleteObject` di Amazon S3 su elementi nel bucket `productionapp`.
All'utente federato vengono assegnate queste autorizzazioni perché le autorizzazioni sono l'intersezione delle policy utente IAM e delle policy di sessione che vengono passate.
L'utente AWS STS federato non poteva eseguire azioni in Amazon SNS, Amazon SQS, Amazon DynamoDB o in nessun bucket S3 tranne. `productionapp` Queste operazioni sono rifiutate anche se tali autorizzazioni sono concesse all'utente IAM associato alla chiamata `GetFederationToken`.
**Example Esempio di policy di sessione passata come parametro della chiamata API `GetFederationToken`.**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::productionapp"]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::productionapp/*"]
}
]
}
```
### Policy basate sulle risorse
Alcune AWS risorse supportano politiche basate sulle risorse e queste politiche forniscono un altro meccanismo per concedere le autorizzazioni direttamente a un utente federato. AWS STS Solo alcuni servizi supportano politiche basate sulle risorse AWS . Ad esempio, Amazon S3 ha i bucket, Amazon SNS ha gli argomenti e Amazon SQS ha le code, tutti elementi ai quali è possibile collegare le policy. Per un elenco di tutti i servizi che supportano le policy basate su risorse, consulta [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md) e analizza la colonna "Policy basate su risorse" delle tabelle. È possibile utilizzare politiche basate sulle risorse per assegnare le autorizzazioni direttamente a un utente federato. AWS STS A tale scopo, specifica l'Amazon Resource Name (ARN) dell' AWS STS utente federato nell'elemento della policy basata `Principal` sulle risorse. Ciò viene illustrato nell'esempio seguente espandendo gli esempi precedenti e utilizzando un bucket S3 denominato `productionapp`.
La policy basata sulle risorse riportata di seguito è collegata al bucket. Questa policy sui bucket consente a un utente AWS STS federato di nome Carol di accedere al bucket. Quando la policy di esempio descritta in precedenza viene allegata all'utente `token-app` IAM, l'utente AWS STS federato di nome Carol è autorizzato a eseguire le azioni e `s3:DeleteObject` le azioni sul `s3:GetObject` `s3:PutObject` bucket denominato. `productionapp` Questo vale anche quando nessuna policy di sessione viene passata come parametro della chiamata API `GetFederationToken`. Questo perché in questo caso all'utente AWS STS federato di nome Carol sono state concesse esplicitamente le autorizzazioni dalla seguente politica basata sulle risorse.
***Ricorda che a un utente AWS STS federato vengono concesse le autorizzazioni solo quando tali autorizzazioni sono concesse esplicitamente sia all'utente IAM che all'utente federato.*** AWS STS Possono anche essere concesse (all'interno dell'account) da una policy basata sulle risorse che nomina esplicitamente l'utente AWS STS federato nell'`Principal`elemento della policy, come nell'esempio seguente.
**Example Esempio di policy del bucket che consente l'accesso all'utente federato**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
Per ulteriori informazioni su come vengono valutate le policy, consulta la sezione [Logica di valutazione delle policy](reference_policies_evaluation-logic.md).
# Autorizzazioni per GetSessionToken
La principale occasione per chiamare l'operazione API `GetSessionToken` o il comando CLI `get-session-token` è quando un utente deve essere autenticato tramite Multi-Factor Authentication (MFA). È possibile scrivere una policy che permette determinate operazioni solo quando tali operazioni vengono richieste da un utente autenticato con MFA. Per superare i controlli di autorizzazione MFA, un utente deve prima chiamare `GetSessionToken` e includere i parametri facoltativi `SerialNumber` e `TokenCode`. Se l'utente è stato autenticato con un dispositivo MFA, le credenziali restituite dall'operazione API `GetSessionToken` includono il contesto MFA. Tale contesto indica che l'utente viene autenticato con MFA ed è autorizzato per le operazioni API che richiedono l'autenticazione MFA.
## Autorizzazioni richieste per GetSessionToken
Non è richiesta all'utente alcuna autorizzazione per ottenere un token di sessione. Lo scopo dell'operazione `GetSessionToken` è autenticare l'utente tramite MFA. Non è possibile utilizzare le policy per controllare le operazioni di autenticazione.
Per concedere le autorizzazioni necessarie per eseguire la maggior parte AWS delle operazioni, è necessario aggiungere l'azione con lo stesso nome a una policy. Ad esempio, per creare un utente, occorre utilizzare l'operazione API `CreateUser`, il comando della CLI `create-user` o la Console di gestione AWS. Per eseguire queste operazioni, è necessario disporre di una policy che consenta di accedere all'operazione `CreateUser`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
]
}
```
------
È possibile includere l'operazione `GetSessionToken` nella policy, ma questo non incide sulla capacità di un utente di eseguire l'operazione `GetSessionToken`.
## Autorizzazioni concesse da GetSessionToken
Se la chiamata a `GetSessionToken` viene eseguita con le credenziali di un utente IAM, le credenziali di sicurezza temporanee avranno le stesse autorizzazioni dell'utente IAM. Allo stesso modo, se `GetSessionToken` viene chiamata con Utente root dell'account AWS credenziali, le credenziali di sicurezza temporanee dispongono dei permessi di utente root.
**Nota**
È consigliabile non chiamare `GetSessionToken` con credenziali dell'utente root Segui invece le [best practice](best-practices-use-cases.md) e crea utenti IAM con le autorizzazioni necessarie. Quindi usa questi utenti IAM per l'interazione quotidiana con. AWS
Le credenziali temporanee ottenute chiamando `GetSessionToken` hanno le funzionalità e le limitazioni seguenti:
+ Puoi utilizzare le credenziali per accedere a passando le credenziali all' Console di gestione AWS endpoint Single Sign-On della federazione all'indirizzo. `https://signin.aws.amazon.com/federation` Per ulteriori informazioni, consulta [Abilita l'accesso personalizzato del broker di identità alla AWS console](id_roles_providers_enable-console-custom-url.md).
+ **Non puoi** utilizzare le credenziali per richiamare le operazioni API IAM o AWS STS . È **possibile** utilizzarle per chiamare le operazioni API per altri servizi. AWS
Per un confronto tra questa operazione API e i relativi limiti e funzionalità con le altre operazioni API che creano credenziali di sicurezza temporanee, consulta [Confronta le AWS STS credenziali](id_credentials_sts-comparison.md)
Per ulteriori informazioni sull'accesso API protetto da MFA con `GetSessionToken`, consulta [Accesso sicuro alle API con MFA](id_credentials_mfa_configure-api-require.md).
# Disabilitazione delle autorizzazioni per le credenziali di sicurezza temporanee
Le credenziali di sicurezza provvisorie sono valide finché non scadono. Queste credenziali sono valide per la durata specificata, da 900 secondi (15 minuti) a un massimo di 129.600 secondi (36 ore). La durata predefinita della sessione è di 43.200 secondi (12 ore). Puoi revocare queste credenziali, ma devi anche modificare le autorizzazioni per il ruolo o l'utente IAM per bloccare l'uso di credenziali compromesse che consentirebbero attività dannose per l'account. Le autorizzazioni assegnate alle credenziali di sicurezza temporanee vengono valutate ogni volta che vengono utilizzate per effettuare una richiesta. AWS Una volta rimosse tutte le autorizzazioni dalle credenziali, le AWS richieste che le utilizzano hanno esito negativo.
Potrebbero essere necessari alcuni minuti prima che gli aggiornamenti delle politicy siano applicati. Per le sessioni del ruolo IAM, puoi revocare le credenziali di sicurezza temporanee del ruolo per obbligare tutti gli utenti che assumono il ruolo a riautenticarsi e richiedere nuove credenziali. Per ulteriori informazioni, consulta [Revoca delle credenziali di sicurezza provvisorie del ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html).
Non è possibile modificare le autorizzazioni per un. Utente root dell'account AWS Analogamente, non puoi modificare le autorizzazioni relative alle credenziali di sicurezza temporanee create richiamando `GetFederationToken` o `GetSessionToken` mentre sei collegato come utente root. Per questo motivo, consigliamo di non effettuare la chiamata a `GetFederationToken` o `GetSessionToken` come utente root.
Per le procedure su come modificare le autorizzazioni per un ruolo IAM, consulta [Modificare le autorizzazioni per un utente IAM](id_users_change-permissions.md).
Per le procedure su come modificare le autorizzazioni per un ruolo IAM, consulta [Aggiornamento delle autorizzazioni per un ruolo](id_roles_update-role-permissions.md).
**Importante**
Non è possibile modificare i ruoli in IAM creati dai set di autorizzazioni del Centro identità IAM. È necessario revocare la sessione attiva del set di autorizzazioni per un utente nel Centro identità IAM. Per ulteriori informazioni, consulta [Revocare le sessioni attive di un ruolo IAM create dai set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) nella *Guida per l'utente del Centro identità IAM*.
**Topics**
+ [Negare l'accesso a tutte le sessioni del ruolo IAM associate a un ruolo](#deny-access-to-all-sessions)
+ [Negare l'accesso a una sessione specifica del ruolo IAM](#deny-access-to-specific-session)
+ [Negare l'accesso alle sessioni delle credenziali di sicurezza temporanee con chiavi di contesto della condizione](#deny-access-to-specific-session-condition-key)
+ [Negare l'accesso a uno specifico principale con policy basate sulle risorse](#deny-access-with-resource-based)
## Negare l'accesso a tutte le sessioni del ruolo IAM associate a un ruolo
Questa procedura nega le autorizzazioni a **tutte** le sessioni del ruolo IAM associate a un ruolo. Usa questo approccio quando hai il dubbio che sia stato effettuato un accesso sospetto da:
+ Principali di un altro account utilizzando l'accesso multi-account
+ Identità di utenti esterni con autorizzazioni per accedere alle AWS risorse del tuo account
+ Utenti che sono stati autenticati in un'applicazione Web o mobile con un provider OIDC
Per modificare o rimuovere le autorizzazioni assegnate alle credenziali di sicurezza provvisorie ottenute richiamando `AssumeRole`, `AssumeRoleWithSAML` o `AssumeRoleWithWebIdentity`, `GetFederationToken` o `GetSessionToken`, puoi modificare o eliminare la policy basata sulle identità che definisce le autorizzazioni per il ruolo.
**Importante**
Se esiste una policy basata sulle risorse che consente l'accesso principale, devi anche aggiungere un rifiuto esplicito per quella risorsa. Per informazioni dettagliate, vedi [Negare l'accesso a uno specifico principale con policy basate sulle risorse](#deny-access-with-resource-based).
**Per negare l'accesso a **tutte** le sessioni del ruolo IAM associate a un ruolo**
1. Accedi Console di gestione AWS e apri la console IAM.
1. Nel riquadro di navigazione, seleziona **Ruoli**.
1. Scegli il nome del ruolo da modificare. Puoi utilizzare la casella di ricerca per filtrare l'elenco.
1. Scegli la scheda **Autorizzazioni**.
1. Seleziona la policy pertinente da modificare. Prima di modificare una policy gestita dal cliente, consulta la scheda **Entità collegate** per evitare di interrompere l'accesso ad altre identità che potrebbero avere la stessa policy associata.
1. Scegli la scheda **JSON** e aggiorna la policy per negare tutte le risorse e le azioni.
**Nota**
Queste autorizzazioni sono le stesse della policy AWS gestita [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html). Puoi allegare questa policy AWS gestita a qualsiasi utente o ruolo IAM a cui desideri negare qualsiasi accesso.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAll",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*"
}
]
}
```
------
1. Nella pagina **Review (Esamina)** controllare **Summary (Riepilogo)** e selezionare **Save changes (Salva modifiche)** per salvare.
Quando si modifica o si elimina la policy, le modifiche riguardano le autorizzazioni di tutte le credenziali di sicurezza provvisorie associate a tale ruolo, tra cui credenziali che sono state rilasciate prima di aver modificato la policy di autorizzazione del ruolo.
Dopo aver aggiornato la policy, è possibile [revocare le credenziali di sicurezza temporanee del ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) per revocare immediatamente tutte le autorizzazioni alle credenziali emesse per il ruolo.
## Negare l'accesso a una sessione specifica del ruolo IAM
Quando aggiorni i ruoli IAM con una policy di negazione totale o elimini completamente il ruolo, tutti gli utenti che hanno accesso al ruolo vengono scollegati. Puoi negare l'accesso senza influire sulle autorizzazioni di tutte le altre sessioni associate al ruolo.
Ai `Principal` possono essere negate le autorizzazioni usando [chiavi di contesto delle condizioni](#deny-access-to-specific-session-condition-key) o [policy basate sulle risorse](#deny-access-with-resource-based).
**Suggerimento**
Puoi trovare gli utenti ARNs federati utilizzando AWS CloudTrail i log. Per ulteriori informazioni, consulta [Come identificare facilmente gli utenti federati utilizzando](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/). AWS CloudTrail
## Negare l'accesso alle sessioni delle credenziali di sicurezza temporanee con chiavi di contesto della condizione
Puoi usare le chiavi di contesto della condizione nelle policy basate sulle identità in situazioni in cui vuoi negare l'accesso a sessioni specifiche con credenziali di sicurezza temporanee senza compromettere le autorizzazioni dell'utente IAM o del ruolo che ha creato le credenziali. Per i ruoli IAM, dopo aver aggiornato la policy, puoi anche [revocare le credenziali di sicurezza temporanee del ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) per revocare immediatamente tutte le credenziali emesse.
Per ulteriori informazioni su queste chiavi di contesto della condizione, consulta [AWS chiavi di contesto della condizione globale](reference_policies_condition-keys.md).
### leggi: PrincipalArn
Puoi usare la chiave di contesto della condizione [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) in una policy basata sull'identità per negare l'accesso a uno specifico principale tramite il relativo nome della risorsa Amazon (ARN). A tale scopo, specificate l'ARN dell'utente, del ruolo AWS STS o della sessione utente federata IAM a cui sono associate le credenziali di sicurezza temporanee nell'elemento Condition di una policy.
**Per negare l'accesso a uno specifico principale tramite il relativo ARN**
1. Nel riquadro di navigazione della console IAM, scegli **Utenti** o **Ruoli**.
1. Scegli il nome dell'utente IAM o del ruolo da modificare. Puoi utilizzare la casella di ricerca per filtrare l'elenco.
1. Scegli la scheda **Autorizzazioni**.
1. Seleziona la policy pertinente da modificare. Prima di modificare una policy gestita dal cliente, consulta la scheda **Entità collegate** per evitare di interrompere l'accesso ad altre identità che potrebbero avere la stessa policy associata.
1. Scegli la scheda **JSON** e aggiungi un'istruzione di negazione per l'ARN principale, come mostrato nell'esempio seguente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:iam::222222222222:federated-user/USERNAME"
]
}
}
}
]
}
```
------
1. Nella pagina **Review (Esamina)** controllare **Summary (Riepilogo)** e selezionare **Save changes (Salva modifiche)** per salvare.
### Leggi: SourceIdentity
Puoi usare la chiave di contesto della condizione [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) in una policy basata sull'identità per negare l'accesso a un'identità di origine specifica associata a una sessione di ruolo IAM. Ciò vale a condizione che la sessione del ruolo sia stata emessa impostando il parametro di `SourceIdentity` richiesta quando il principale ha assunto un ruolo utilizzando qualsiasi AWS STS `assume-role` comando\$1 CLI AWS STS `AssumeRole` o\$1 operazioni API. A tale scopo, devi specificare l'identità di origine a cui sono associate le credenziali di sicurezza temporanee nell'elemento `Condition` di una policy.
A differenza della chiave di contesto [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname), dopo aver impostato l'identità di origine, il valore non può essere modificato. La chiave `aws:SourceIdentity` è presente nel contesto della richiesta di tutte le operazioni intraprese dal ruolo. L'identità di origine persiste nelle sessioni di ruolo successive quando si utilizzano le credenziali di sessione per assumere un altro ruolo. L'assunzione di un ruolo partendo da un altro si chiama [concatenamento del ruolo](id_roles.md#iam-term-role-chaining).
La seguente policy mostra un esempio di come puoi negare l'accesso a sessioni con credenziali di sicurezza temporanee utilizzando la chiave di contesto della condizione.`aws:SourceIdentity`. Se specifichi l'identità di origine associata a una sessione del ruolo, verranno negate le sessioni di ruolo con l'identità di origine specificata senza influire sulle autorizzazioni del ruolo che ha creato le credenziali. Per questo esempio, l'identità di origine impostata dal principale al momento dell'emissione della sessione di ruolo è `nikki_wolf@example.com`. Qualsiasi richiesta effettuata da una sessione di ruolo con l'identità di origine `nikki_wolf@example.com` verrà rifiutata perché l'identità di origine è inclusa nella condizione della policy e la policy Effect è impostata su `Deny`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
]
}
```
------
### aws:userid
Puoi usare la chiave di contesto della condizione [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) in una policy basata sulle identità per negare l'accesso a tutte o a specifiche sessioni con credenziali di sicurezza temporanee associate all'utente o al ruolo IAM. A tale scopo, è necessario specificare l'identificatore univoco (ID) dell'utente, del ruolo o della sessione utente AWS STS federata IAM a cui sono associate le credenziali di sicurezza temporanee nell'`Condition`elemento di una policy.
La seguente policy mostra un esempio di come puoi negare l'accesso a sessioni con credenziali di sicurezza temporanee utilizzando la chiave di contesto della condizione.`aws:userid`.
+ `AIDAXUSER1` rappresenta l'ID univoco per un utente IAM. Specificando l'ID univoco di un utente IAM come valore per la chiave di contesto `aws:userid`verrà negato l'accesso all'utente IAM. Ciò include tutte le sessioni di credenziali di sicurezza temporanee create chiamando l'API `GetSessionToken`.
+ `AROAXROLE1:*` rappresenta l'ID univoco per tutte le sessioni associate al ruolo IAM. Specificando l'ID univoco di un ruolo IAM e un carattere jolly (\$1) nella parte caller-specified-role-session -name come valore per la chiave di contesto `aws:userid` verranno negate tutte le sessioni associate al ruolo.
+ `AROAXROLE2:` rappresenta l'ID univoco per una sessione del ruolo assunto. Nella parte caller-specified-role-session -name dell'ID univoco del ruolo assunto è possibile specificare un nome di sessione del ruolo o un carattere jolly se viene utilizzato l'operatore condition. StringLike Se specifichi il nome di sessione del ruolo, verrà negata la sessione di ruolo denominata senza influire sulle autorizzazioni del ruolo che ha creato le credenziali. Se specifichi un carattere jolly per il nome della sessione del ruolo, verranno negate tutte le sessioni associate al ruolo.
**Nota**
Il nome della sessione di ruolo specificato dal chiamante, che fa parte dell'identificatore univoco di una sessione del ruolo assunto, può cambiare durante il concatenamento dei ruoli. Il concatenamento dei ruoli si verifica quando un ruolo assume un altro ruolo. Il nome della sessione di ruolo viene impostato utilizzando il parametro `RoleSessionName` request quando il principale assume un ruolo utilizzando l'operazione API. AWS STS `AssumeRole`
+ `account-id:`rappresenta l'ID univoco per una sessione utente AWS STS federata. Un utente IAM crea questa sessione chiamando l'API `GetFederationToken`. Se specifichi l’ID univoco per una sessione dell’utente federato AWS STS , la sessione federata denominata verrà negata senza influire sulle autorizzazioni dell’utente IAM che ha creato le credenziali.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userId": [
"AIDAXUSER1",
"AROAXROLE1:*",
"AROAXROLE2:",
"123456789012:"
]
}
}
}
]
}
```
------
Per esempi specifici di valori chiave del principale, consulta [Valori della chiave dell'entità principale](reference_policies_variables.md#principaltable). Per ulteriori informazioni sugli identificatori univoci IAM e su come ottenerli, consulta[Identificatori univoci](reference_identifiers.md#identifiers-unique-ids).
## Negare l'accesso a uno specifico principale con policy basate sulle risorse
Per limitare l'accesso a un principale specifico con una policy basata sulle risorse, puoi utilizzare le chiavi di contesto delle condizioni [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) o [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) nell'elemento `Condition`. Una policy basata sulle risorse è una policy di autorizzazione collegata a una risorsa che controlla chi può accedere alla risorsa e quali azioni è possibile eseguire su di essa.
Quando utilizzi la chiave di `aws:PrincipalARN` contesto, specifica l'ARN dell'utente, del ruolo o della sessione utente AWS STS federata IAM associata alle credenziali di sicurezza temporanee nell'elemento Condition di una policy. Il seguente esempio di policy mostra come utilizzare la chiave di contesto `aws:PrincipalARN` in una policy basata sulle risorse:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:sts::222222222222:federated-user/USERNAME"
]
}
}
}
}
```
------
Quando si utilizza la chiave di contesto `aws:SourceIdentity`, specifica il valore di identità di origine associato alle credenziali di sicurezza temporanee del ruolo nell'elemento `Condition` di una policy. Ciò vale a condizione che la sessione del ruolo sia stata emessa impostando il parametro di `SourceIdentity` richiesta quando il principale ha assunto un ruolo utilizzando qualsiasi AWS STS `assume-role` comando\$1 CLI AWS STS `AssumeRole` o\$1 operazioni API. Il seguente esempio di policy mostra come utilizzare la chiave di contesto `aws:SourceIdentity` in una policy basata sulle risorse:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
}
```
------
Se aggiorni solo la policy basata sull'identità per un principale, questo può comunque eseguire le azioni consentite nella policy basata sulle risorse, a meno che tali azioni siano negate esplicitamente nella policy basata sull'identità.
**Per negare l'accesso a uno specifico principale con una policy basata sulle risorse**
1. Fai riferimento a [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md) per verificare se il servizio supporta policy basate sulle risorse.
1. Accedi Console di gestione AWS e apri la console per il servizio. Ogni servizio ha una posizione diversa nella console per allegare le policy.
1. Modifica la policy basata sulle risorse. Aggiungi un'istruzione di negazione della policy per specificare le informazioni identificative delle credenziali:
1. Nell'elemento `Principal`, inserisci un carattere jolly (\$1). Il principale sarà limitato nell'elemento `Condition`.
1. Nell'elemento `Effect`, inserisci "Nega".
1. In `Action`, inserisci il namespace del servizio e il nome dell’azione da rifiutare. Per negare tutte le azioni, usa il carattere jolly (\$1). Ad esempio: `"s3:*"`.
1. Nell'elemento `Resource`, inserisci l'ARN della risorsa di destinazione. Ad esempio: `"arn:aws:s3:::amzn-s3-demo-bucket"`.
1. Nell'elemento `Condition`, specifica la chiave di contesto `aws:PrincipalARN` o `aws:SourceIdentity`.
Se si utilizza la chiave di contesto `aws:PrincipalARN`, immetti l'ARN del principale a cui negare l'accesso.
Se utilizzi la chiave di contesto `aws:SourceIdentity`, inserisci il valore dell'identità di origine impostato nella sessione del ruolo a cui negare l'accesso.
1. Salva il tuo lavoro.
# Concessione delle autorizzazioni per creare credenziali di sicurezza temporanee
Per impostazione predefinita, gli utenti IAM non dispongono dell’autorizzazione per creare credenziali di sicurezza temporanee per ruoli e sessioni di utenti federati AWS STS . È necessario utilizzare una policy per fornire queste autorizzazioni agli utenti. Anche se è possibile concedere le autorizzazioni direttamente a un utente, ti consigliamo caldamente di assegnarle a un gruppo. In questo modo la gestione delle autorizzazioni risulta molto più semplice. Quando un utente non ha più bisogno di eseguire le operazioni associate alle autorizzazioni, non dovrai fare altro che rimuoverlo dal gruppo. Se un'altra persona si trova nella necessità di eseguire tale operazione, sarà sufficiente aggiungerla al gruppo per concederle le autorizzazioni.
Per concedere a un gruppo IAM l’autorizzazione per creare credenziali di sicurezza temporanee per ruoli o sessioni di utenti federati AWS STS , puoi collegare una policy che conceda uno o entrambi i seguenti privilegi:
+ Affinché i principali federati OIDC e SAML possano accedere a un ruolo IAM, concedi l'accesso a. AWS STS `AssumeRole`
+ Per gli utenti AWS STS federati che non necessitano di un ruolo, concedi l'accesso a. AWS STS `GetFederationToken`
Per informazioni sulle differenze fra le operazioni API `AssumeRole` e `GetFederationToken`, consultare [Richiedere credenziali di sicurezza temporanee](id_credentials_temp_request.md).
Per creare le credenziali di sicurezza temporanee, gli utenti IAM possono chiamare anche [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html). Non sono necessarie autorizzazioni perché un utente possa chiamare `GetSessionToken`. Lo scopo dell'operazione è autenticare l'utente tramite MFA. Non è possibile utilizzare le policy per controllare l'autenticazione. Ciò significa che non puoi impedire agli utenti IAM di chiamare `GetSessionToken` per creare le credenziali temporanee.
**Example Esempio di policy che concede autorizzazioni per assumere un ruolo**
La politica di esempio seguente concede l'autorizzazione a `AssumeRole` richiedere il `UpdateApp` ruolo in. Account AWS `123123123123` Quando si usa `AssumeRole`, l'utente (o l'applicazione) che crea le credenziali di sicurezza per conto di un utente federato non è in grado di delegare autorizzazioni che non siano già state specificate nella policy di autorizzazione del ruolo.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
```
**Example Esempio di policy che concede l'autorizzazione per creare credenziali di sicurezza temporanee per un utente federato.**
La policy dell'esempio seguente concede l'autorizzazione per l'accesso a `GetFederationToken`.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}]
}
```
**Importante**
Quando si autorizzano utenti IAM a creare credenziali di sicurezza temporanee per gli utenti federati AWS STS con `GetFederationToken`, tieni a mente che tali utenti avranno la possibilità di delegare le proprie autorizzazioni. Per ulteriori informazioni sulla delega delle autorizzazioni tra utenti IAM e Account AWS, consulta. [Esempi di policy per la delega dell'accesso](id_roles_create_policy-examples.md) Per informazioni sul controllo delle autorizzazioni nelle credenziali di sicurezza provvisorie, vedi [Autorizzazioni per le credenziali di sicurezza temporanee](id_credentials_temp_control-access.md).
**Example Esempio di policy che concede a un utente autorizzazioni limitate per creare credenziali di sicurezza temporanee per utenti federati.**
Quando si consente a un utente IAM di chiamare `GetFederationToken`, una best practice consiste nel limitare le autorizzazioni che l'utente IAM può delegare. *Ad esempio, la seguente policy mostra come consentire a un utente IAM di creare credenziali di sicurezza temporanee solo per gli utenti AWS STS federati i cui nomi iniziano con Manager.*
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
```
# Concessione delle autorizzazioni per l’utilizzo di sessioni di console rafforzate con l’identità
Le sessioni di console con identità migliorata consentono di includere AWS IAM Identity Center utenti e sessioni nelle sessioni della AWS console degli utenti IDs al momento dell'accesso. Ad esempio, Amazon Q Developer Pro utilizza sessioni di console rafforzate con l’identità per personalizzare l’esperienza del servizio. Per ulteriori informazioni sulle sessioni di console rafforzate con l’identità, consulta [Enabling identity-enhanced console sessions](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html) nella *Guida per l’utente di AWS IAM Identity Center *. Per informazioni sulla configurazione di Amazon Q Developer, consulta [Configurazione di Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html) nella *Guida per l'utente di Amazon Q Developer*.
Affinché le sessioni di console rafforzate con l’identità siano disponibili per un utente, è necessario utilizzare una policy basata sull’identità per concedere al principale IAM l’autorizzazione `sts:SetContext` per la risorsa che rappresenta la propria sessione di console.
**Importante**
Per impostazione predefinita, gli utenti non dispongono dell’autorizzazione per impostare il contesto per le sessioni di console rafforzate con l’identità. Per consentire ciò, è necessario concedere al principale IAM l'autorizzazione `sts:SetContext` in una policy basata sull'identità, come illustrato nell'esempio di policy riportato di seguito.
L'esempio seguente di policy basata sull'identità concede l'`sts:SetContext`autorizzazione a un principale IAM, che consente al principale di impostare un contesto di sessione di console con identità migliorata per le proprie sessioni di console. AWS La risorsa policy,, `arn:aws:sts::account-id:self` rappresenta la sessione del chiamante. AWS Il segmento dell'ARN di `account-id` può essere sostituito con un carattere jolly `*` nei casi in cui la stessa policy di autorizzazione viene implementata su più account, ad esempio quando questa policy viene implementata utilizzando i set di autorizzazioni del Centro identità IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:SetContext",
"Resource": "arn:aws:sts::111122223333:self"
}
]
}
```
------