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à. # Credenziali di sicurezza temporanee in IAM Puoi utilizzare il 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. Le credenziali di sicurezza temporanee funzionano quasi esattamente come le credenziali delle chiavi di accesso a lungo termine, con le seguenti differenze: + Le credenziali di sicurezza provvisorie sono *a breve termine*, come implica il nome. Possono essere configurate per durare ovunque per pochi minuti o diverse ore. Una volta scadute, le credenziali AWS non le riconosce più né consente alcun tipo di accesso alle richieste API effettuate con esse. + Le credenziali di sicurezza temporanee non sono archiviate con l'utente, ma vengono generate dinamicamente e fornite all'utente quando richiesto. Quando (o anche prima) le credenziali di sicurezza temporanee scadono, l'utente può richiedere nuove credenziali, purché l'utente che le richiede abbia ancora le autorizzazioni per farlo. Di conseguenza, le credenziali temporanee presentano i seguenti vantaggi rispetto alle credenziali a lungo termine: + Non è necessario distribuire o incorporare credenziali di AWS sicurezza a lungo termine in un'applicazione. + È possibile fornire l'accesso alle AWS risorse agli utenti senza dover definire un' AWS identità per loro. Le credenziali provvisorie sono la base dei [ruoli](id_roles.md) e della [federazione delle identità](id_roles_providers.md). + Le credenziali di sicurezza temporanee hanno una durata limitata, perciò non è necessario aggiornarle o revocarle in modo esplicito quando non sono più necessarie. Dopo che le credenziali di sicurezza temporanee scadono, non possono essere riutilizzate. È possibile specificare quando scadono le credenziali, fino a un limite massimo. ## AWS STS e AWS regioni Le credenziali di sicurezza temporanee sono generate da AWS STS. Per impostazione predefinita, AWS STS è un servizio globale con un unico endpoint su`https://sts.amazonaws.com`. Tuttavia, puoi anche scegliere di effettuare chiamate AWS STS API verso endpoint in qualsiasi altra regione supportata. Ciò può ridurre la latenza (server lag) effettuando le richieste a server in una regione geograficamente più vicina a te. Indipendentemente dalla regione dalla quale provengono, le credenziali funzionano a livello globale. Per ulteriori informazioni, consulta [Gestisci AWS STS in un Regione AWS](id_credentials_temp_enable-regions.md). ## Scenari comuni per le credenziali temporanee Le credenziali temporanee sono utili in scenari che interessano la federazione delle identità, la delega, l'accesso tra account e i ruoli IAM. ### Federazione delle identità Puoi gestire le tue identità utente in un sistema esterno esterno AWS e concedere agli utenti che accedono da tali sistemi l'accesso per eseguire AWS attività e accedere alle tue AWS risorse. IAM supporta due tipi di federazione delle identità. In entrambi i casi, le identità vengono archiviate all'esterno di. AWS La differenza è dove risiede il sistema esterno: nel data center o una parte terza sul Web. Per confrontare le funzionalità delle credenziali di sicurezza temporanee per la federazione delle identità, consulta [Confronta le AWS STS credenziali](id_credentials_sts-comparison.md). Per ulteriori informazioni sui provider di identità esterni, consultare [Provider di identità e federazione in AWS](id_roles_providers.md). + **Federazione OpenID Connect (OIDC)**: puoi consentire agli utenti di effettuare l'accesso tramite un provider di identità di terze parti noto, come Login with Amazon, Facebook, Google o qualsiasi provider compatibile con OpenID Connect (OIDC) 2.0 per l'applicazione mobile o Web, non è necessario creare un codice di accesso personalizzato o gestire le proprie identità utente. L'utilizzo della federazione OIDC aiuta a mantenere la Account AWS sicurezza, in quanto non è necessario distribuire credenziali di sicurezza a lungo termine, come le chiavi di accesso utente IAM, con l'applicazione. Per ulteriori informazioni, consulta [Federazione OIDC](id_roles_providers_oidc.md). AWS STS La federazione OIDC supporta Login with Amazon, Facebook, Google e qualsiasi provider di identità compatibile con OpenID Connect (OIDC). **Nota** Per le applicazioni mobili, consigliamo di utilizzare Amazon Cognito. Puoi utilizzare questo servizio per lo sviluppo mobile AWS SDKs per creare identità uniche per gli utenti e autenticarle per un accesso sicuro alle tue risorse. AWS Amazon Cognito supporta gli stessi provider di identità e supporta anche l'accesso non autenticato (guest) e consente di migrare i dati degli utenti quando un utente accede. AWS STS Amazon Cognito fornisce inoltre operazioni API per la sincronizzazione dei dati utente in modo che vengano conservati quando gli utenti passano da un dispositivo all'altro. Per ulteriori informazioni, consulta [Autenticazione con Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) nella *documentazione di Amplify*. + **Federazione SAML**: puoi autenticare gli utenti nella rete della tua organizzazione e quindi fornire loro l'accesso AWS senza creare nuove AWS identità per loro e richiedere loro di accedere con credenziali di accesso diverse. Questo è noto come approccio *Single Sign-On all'accesso temporaneo*. AWS STS supporta standard aperti come Security Assertion Markup Language (SAML) 2.0, con cui è possibile utilizzare Microsoft AD FS per sfruttare Microsoft Active Directory. È inoltre possibile utilizzare SAML 2.0 per gestire la soluzione per la federazione delle identità dell'utente. Per ulteriori informazioni, consulta [Federazione SAML 2.0](id_roles_providers_saml.md). + **Broker federativo personalizzato**: puoi utilizzare il sistema di autenticazione della tua organizzazione per concedere l'accesso alle risorse. AWS Per uno scenario di esempio, consultare [Abilita l'accesso personalizzato del broker di identità alla AWS console](id_roles_providers_enable-console-custom-url.md). + **Federazione tramite SAML 2.0**: puoi utilizzare SAML e il sistema di autenticazione dell'organizzazione per concedere l'accesso alle risorse AWS . Per ulteriori informazioni e uno scenario di esempio, consultare [Federazione SAML 2.0](id_roles_providers_saml.md). ### Ruoli per l'accesso tra account Molte organizzazioni mantengono più di un Account AWS. Utilizzando ruoli e l'accesso tra account, è possibile definire le identità degli utenti in un account e utilizzare tali identità per accedere alle risorse AWS in altri account che appartengono all'organizzazione. Questo approccio è noto come *delega* all'accesso temporaneo. Per ulteriori informazioni sulla creazione di ruoli tra account, consulta la sezione [Creazione di un ruolo per fornire le autorizzazioni a un utente IAM](id_roles_create_for-user.md). Per capire se i principali negli account esterni alla zona di attendibilità (organizzazione o account attendibile) dispongono dell'accesso per assumere i ruoli, consulta [Cos'è IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). ### Ruoli per Amazon EC2 Se esegui applicazioni sulle istanze Amazon EC2 e tali applicazioni devono accedere alle risorse AWS , puoi fornire le credenziali di sicurezza temporanee alle istanze al momento dell'avvio. Queste credenziali di sicurezza temporanee sono disponibili a tutte le applicazioni che vengono eseguite sull'istanza, perciò non è necessario archiviare nessuna delle credenziali a lungo termine sull'istanza. Per ulteriori informazioni, consulta [Utilizzare un ruolo IAM per concedere autorizzazioni alle applicazioni in esecuzione su istanze Amazon EC2](id_roles_use_switch-role-ec2.md). Per ulteriori informazioni sulle credenziali del ruolo IAM di Amazon EC2, consulta [Ruoli IAM per Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) nella *Guida per l'utente di Elastic Compute Cloud*. ### Altri AWS servizi È possibile utilizzare credenziali di sicurezza temporanee per accedere alla maggior parte dei AWS servizi. Per un elenco dei servizi che accettano le credenziali di sicurezza temporanee, consultare [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md). ## Applicazioni di esempio che usano credenziali 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). Per scoprire come gestire le credenziali AWS STS di sicurezza temporanee, è possibile scaricare le seguenti applicazioni di esempio che implementano scenari di esempio completi: + [Abilitazione della federazione all' AWS utilizzo di Windows Active Directory, ADFS e SAML 2.0](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/). Dimostra come delegare l'accesso tramite la federazione aziendale all'utilizzo di Windows Active Directory (AD), Active Directory Federation Services (ADFS) 2.0 e SAML (Security Assertion Markup Language) 2.0. AWS + [Abilita l'accesso personalizzato del broker di identità alla AWS console](id_roles_providers_enable-console-custom-url.md). Dimostra come creare un proxy di federazione personalizzato che abilita l'autenticazione unica (SSO) in modo che gli utenti esistenti di Active Directory possano accedere alla Console di gestione AWS. + [Come usare Shibboleth per il Single Sign-On su. Console di gestione AWS](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/) . Mostra come utilizzare [Shibboleth](http://shibboleth.net/) e [SAML](id_roles_providers_saml.md) per fornire agli utenti l'accesso Single Sign-On (SSO) alla Console di gestione AWS. ### Esempi per la federazione OIDC Le seguenti applicazioni di esempio illustrano come utilizzarle OIDCfederation con provider come Login with Amazon, Amazon Cognito, Facebook o Google. Puoi scambiare l'autenticazione di questi provider con credenziali di AWS sicurezza temporanee per accedere ai servizi. AWS + [Tutorial Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html): ti consigliamo di utilizzare Amazon Cognito con lo sviluppo per dispositivi mobili. AWS SDKs Amazon Cognito offre il modo più semplice per gestire l'identità per le applicazioni per dispositivi mobili e offre funzionalità aggiuntive come la sincronizzazione e l'identità tra più dispositivi. Per ulteriori informazioni su Amazon Cognito, consulta [Autenticazione con Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) nella *documentazione di Amplify*. ## Risorse aggiuntive per le credenziali di sicurezza temporanee I seguenti scenari e applicazioni possono essere utili per l'utilizzo di credenziali di sicurezza temporanee: + [Come effettuare l'integrazione AWS STS SourceIdentity con il tuo provider di identità](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/). Questo post mostra come configurare l' AWS STS `SourceIdentity`attributo quando usi Okta, Ping o OneLogin come IdP. + [Federazione OIDC](id_roles_providers_oidc.md). In questa sezione viene descritto come configurare i ruoli IAM quando si utilizza la federazione OIDC e l'API `AssumeRoleWithWebIdentity`. + [Accesso sicuro alle API con MFA](id_credentials_mfa_configure-api-require.md). In questo argomento viene descritto come utilizzare i ruoli per richiedere l'autenticazione a più fattori (MFA) per proteggere le operazioni API sensibili nel tuo account. Per ulteriori informazioni sulle politiche e le autorizzazioni, AWS consulta i seguenti argomenti: + [Gestione degli accessi AWS alle risorse](access.md) + [Logica di valutazione delle policy](reference_policies_evaluation-logic.md). + [Gestione delle autorizzazioni di accesso alle risorse di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) in *Guida per l'utente di Amazon Simple Storage Service*. + Per capire se i principali negli account esterni alla zona di attendibilità (organizzazione o account attendibile) dispongono dell'accesso per assumere i ruoli, consulta [Cos'è IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). # Confronta le AWS STS credenziali La tabella seguente confronta le funzionalità delle operazioni API AWS STS che restituiscono credenziali di sicurezza temporanee. Per informazioni sui diversi metodi che si possono utilizzare per richiedere le credenziali di sicurezza temporanee assumendo un ruolo, consultare [Metodi per assumere un ruolo](id_roles_manage-assume.md). Per ulteriori informazioni sulle diverse operazioni AWS STS API che consentono di passare i tag di sessione, consulta. [Passa i tag di sessione AWS STS](id_session-tags.md) **Nota** Puoi inviare chiamate AWS STS API a un endpoint globale o a uno degli endpoint regionali. Se si seleziona un endpoint vicino, è possibile ridurre la latenza e migliorare le prestazioni delle chiamate API. Se non è più possibile comunicare con l'endpoint originale è anche possibile scegliere di indirizzare le chiamate verso un endpoint regionale alternativo. Se utilizzi uno dei vari AWS SDKs, utilizza il metodo SDK per specificare una regione prima di effettuare la chiamata API. Se costruiscono manualmente richieste API HTTP, è necessario indirizzare la richiesta all'endpoint corretto. Per ulteriori informazioni, consulta la [sezione AWS STS relativa alle *regioni e agli endpoint*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) e la sezione [Gestisci AWS STS in un Regione AWS](id_credentials_temp_enable-regions.md). | **AWS STS API** | **Chi può chiamare** | **Ciclo di vita delle credenziali (minimo \$1 massimo \$1 predefinito)** | **Supporto MFA**¹ | **Supporto di policy di sessione**² | **Restrizioni per le credenziali provvisorie risultanti** | | --- | --- | --- | --- | --- | --- | | [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) | Utente IAM o ruolo IAM con credenziali di sicurezza temporanee esistenti | 15 min \$1 Impostazione durata massima della sessione³ \$1 1 ora | Sì | Sì | Non è possibile chiamare `GetFederationToken` o `GetSessionToken`. | | [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | Qualsiasi intermediario utente deve passare una risposta di autenticazione SAML che indica l'autenticazione da un provider di identità noto | 15 min \$1 Impostazione durata massima della sessione³ \$1 1 ora | No | Sì | Non è possibile chiamare `GetFederationToken` o `GetSessionToken`. | | [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | Qualsiasi utente; il chiamante deve passare un token JWT conforme a OIDC che indica l'autenticazione da un provider di identità noto | 15 min \$1 Impostazione durata massima della sessione³ \$1 1 ora | No | Sì | Non è possibile chiamare `GetFederationToken` o `GetSessionToken`. | | [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | Utente IAM o Utente root dell'account AWS | Utente IAM: 15 m \$1 36 ore \$1 12 ore Utente root: 15 m \$1 1 ora \$1 1 ora | No | Sì | Impossibile chiamare le operazioni IAM utilizzando l' AWS API AWS CLI o. Questa limitazione non si applica alle sessioni della console. Impossibile chiamare AWS STS le operazioni ad eccezione di `GetCallerIdentity` .4 L'accesso SSO alla console è consentito.⁵ | | [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | Utente IAM o Utente root dell'account AWS | Utente IAM: 15 m \$1 36 ore \$1 12 ore Utente root: 15 m \$1 1 ora \$1 1 ora | Sì | No | Impossibile chiamare le operazioni API IAM a meno che le informazioni di MFA siano incluse con la richiesta. Impossibile chiamare le operazioni AWS STS API tranne `AssumeRole` o`GetCallerIdentity`. L'accesso SSO alla console non è consentito.⁶ | ¹ **Supporto MFA**. Puoi includere informazioni su un dispositivo di autenticazione a più fattori (MFA) quando chiami AssumeRole le operazioni GetSessionToken e API. In questo modo le credenziali di sicurezza provvisorie risultanti dalla chiamata API possono essere utilizzate solo dagli utenti autenticati con un dispositivo MFA. Per ulteriori informazioni, consulta [Accesso sicuro alle API con MFA](id_credentials_mfa_configure-api-require.md). ² **Supporto per la policy di sessione**. I criteri di sessione sono criteri che vengono passati come parametro quando si crea a livello di codice una sessione temporanea per un ruolo o AWS STS una sessione utente federata. Questa policy limita le autorizzazioni dalla policy basata su identità del ruolo o dell'utente che sono assegnate alla sessione. Le autorizzazioni della sessione risultanti sono l'intersezione delle policy basate sull'identità dell'entità e delle 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). ³ **Impostazione della durata massima della sessione**. Utilizzare il parametro `DurationSeconds` per specificare la durata della sessione del ruolo da 900 secondi (15 minuti) fino all'impostazione di durata massima della sessione per il ruolo. Per informazioni su come visualizzare il valore massimo per il ruolo, consulta [Aggiornamento della durata massima della sessione per un ruolo](id_roles_update-role-settings.md#id_roles_update-session-duration). 3. **GetCallerIdentity** Non sono necessarie autorizzazioni per eseguire questa operazione. Se un amministratore aggiunge una policy al tuo utente o ruolo IAM che nega esplicitamente l'accesso all'operazione `sts:GetCallerIdentity`, puoi comunque eseguire questa operazione. Le autorizzazioni non sono necessarie perché le stesse informazioni vengono restituite quando a un utente o ruolo IAM viene negato l'accesso. Per visualizzare un esempio di risposta, consulta [Non sono autorizzato a eseguire: iam: DeleteVirtual MFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa). ⁵ **Accesso Single Sign-On (SSO) alla console**. Per supportare l'SSO, AWS consente di chiamare un endpoint di federazione (`https://signin.aws.amazon.com/federation`) e passare credenziali di sicurezza temporanee. L'endpoint restituisce un token che è possibile utilizzare per creare un URL che effettua l'accesso di un utente direttamente nella console senza richiedere una password. Per ulteriori informazioni, consulta [Consentire ai principali federati SAML 2.0 di accedere a Console di gestione AWS](id_roles_providers_enable-console-saml.md) e [Come abilitare l'accesso tra più account alla console di AWS gestione nel blog](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) sulla sicurezza. AWS ⁶ Dopo aver recuperato le credenziali provvisorie, non è possibile accedere alla Console di gestione AWS inoltrando le credenziali all'endpoint Single Sign-On della federazione. Per ulteriori informazioni, consulta [Abilita l'accesso personalizzato del broker di identità alla AWS console](id_roles_providers_enable-console-custom-url.md). # Token di connessione al servizio Alcuni AWS servizi richiedono l'autorizzazione per ottenere un token AWS STS service bearer prima di poter accedere alle loro risorse a livello di programmazione. Questi servizi supportano un protocollo che richiede l'utilizzo di un token di connessione invece di utilizzare un [AWS Signature Version 4 per richieste API](reference_sigv.md) tradizionale. Quando esegui AWS CLI o esegui operazioni AWS API che richiedono token al portatore, il AWS servizio richiede un token al portatore per tuo conto. Il servizio fornisce il token, che è possibile utilizzare per eseguire le operazioni successive in tale servizio. AWS STS i service bearer token includono informazioni relative all'autenticazione principale originale che potrebbero influire sulle autorizzazioni dell'utente. Queste informazioni possono includere tag del principale, tag di sessione e policy di sessione. L'ID chiave di accesso del token inizia con il prefisso `ABIA`. Ciò consente di identificare le operazioni eseguite utilizzando i token di connessione al servizio nei log CloudTrail. **Importante** Il token di connessione può essere utilizzato solo per le chiamate al servizio che lo genera e nella regione in cui è stato generato. Non è possibile utilizzare il token di connessione per eseguire operazioni in altri servizi o regioni. Un esempio di servizio che supporta i bearer token è. AWS CodeArtifact Prima di poter interagire AWS CodeArtifact utilizzando un gestore di pacchetti come NPM, Maven o PIP, è necessario chiamare l'operazione. `aws codeartifact get-authorization-token` Questa operazione restituisce un token portatore che è possibile utilizzare per eseguire operazioni. AWS CodeArtifact In alternativa, è possibile utilizzare il comando `aws codeartifact login` che completa la stessa operazione e quindi configura automaticamente il client. Se esegui un'azione in un AWS servizio che genera un token bearer per te, devi disporre delle seguenti autorizzazioni nella tua politica IAM: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowServiceBearerToken", "Effect": "Allow", "Action": "sts:GetServiceBearerToken", "Resource": "*" } ] } ``` ------ Per un esempio di token portatore di servizi, consulta [Utilizzo di policy basate sulle identità per AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html) nella *Guida per l'utente di AWS CodeArtifact*. # Richiedere credenziali di sicurezza temporanee Per richiedere credenziali di sicurezza temporanee, puoi utilizzare le operazioni AWS Security Token Service (AWS STS) nell' AWS API. Queste includono operazioni per creare e fornire a utenti affidabili credenziali di sicurezza temporanee in grado di controllare l'accesso alle AWS risorse. Per ulteriori informazioni su AWS STS, vedere[Credenziali di sicurezza temporanee in IAM](id_credentials_temp.md). Per informazioni sui diversi metodi che si possono utilizzare per richiedere credenziali di sicurezza temporanee assumendo un ruolo, consultare [Metodi per assumere un ruolo](id_roles_manage-assume.md). Per chiamare le operazioni API, puoi utilizzare uno dei [AWS SDKs](https://aws.amazon.com/tools/). SDKs Sono disponibili per una varietà di linguaggi e ambienti di programmazione, tra cui Java, .NET, Python, Ruby, Android e iOS. SDKs Si occupano di attività come firmare crittograficamente le richieste, riprovare le richieste se necessario e gestire le risposte agli errori. [Puoi anche utilizzare l'API AWS STS Query, descritta nell'API Reference.AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/) Infine, due strumenti da riga di comando supportano i AWS STS comandi: the [AWS Command Line Interface](https://aws.amazon.com/documentation/cli), e the [AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell). Le operazioni AWS STS API creano una nuova sessione con credenziali di sicurezza temporanee che includono una coppia di chiavi di accesso e un token di sessione. La coppia di chiavi di accesso è composta da un ID chiave di accesso e da una chiave segreta. Gli utenti (o un'applicazione che l'utente esegue) possono utilizzare queste credenziali per accedere alle risorse. È possibile creare una sessione di ruolo e passare policy di sessione e tag di sessione in modo programmatico utilizzando AWS STS le operazioni API. Le autorizzazioni della sessione risultanti sono l'intersezione tra le policy basate sull'identità del ruolo e le policy di sessione. Per ulteriori informazioni sulle policy di sessione, consulta [Policy di sessione](access_policies.md#policies_session). Per ulteriori informazioni sui tag di sessione, consultare [Passa i tag di sessione AWS STS](id_session-tags.md). **Nota** La dimensione del token di sessione restituito dalle operazioni AWS STS API non è fissa. È consigliabile di non effettuare alcuna supposizione sulle dimensioni massime. La dimensione tipica dei token è inferiore a 4.096 byte, ma essa può variare. ## Utilizzo AWS STS con AWS le regioni Puoi inviare chiamate AWS STS API a un endpoint globale o a uno degli endpoint regionali. Se si seleziona un endpoint vicino, è possibile ridurre la latenza e migliorare le prestazioni delle chiamate API. Se non è più possibile comunicare con l'endpoint originale è anche possibile scegliere di indirizzare le chiamate verso un endpoint regionale alternativo. Se utilizzi uno dei vari AWS SDKs, utilizza il metodo SDK per specificare una regione prima di effettuare la chiamata API. Se costruiscono manualmente richieste API HTTP, è necessario indirizzare la richiesta all'endpoint corretto. Per ulteriori informazioni, consulta la [sezione AWS STS relativa alle *regioni e agli endpoint*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) e la sezione [Gestisci AWS STS in un Regione AWS](id_credentials_temp_enable-regions.md). Di seguito sono elencate le operazioni API che è possibile utilizzare per acquisire credenziali temporanee da utilizzare nell' AWS ambiente e nelle applicazioni. ## Richiesta di credenziali per la delega tra account e federazione tramite un gestore di identità personalizzato 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 è utile per consentire agli utenti IAM esistenti di accedere a AWS risorse a cui non hanno già accesso. Ad esempio, l'utente potrebbe aver bisogno di accedere alle risorse in un altro Account AWS. Inoltre, è utile come strumento per ottenere temporaneamente l'accesso privilegiato, ad esempio per fornire l'autenticazione a più fattori (MFA). È necessario chiamare questa API utilizzando le credenziali attive. Per sapere chi può chiamare questa operazione, vedere [Confronta le AWS STS credenziali](id_credentials_sts-comparison.md). Per ulteriori informazioni, consultare [Creazione di un ruolo per fornire le autorizzazioni a un utente IAM](id_roles_create_for-user.md) e [Accesso sicuro alle API con MFA](id_credentials_mfa_configure-api-require.md). **Per richiedere credenziali di sicurezza temporanee per la delega tra account e federazione tramite un gestore di identità personalizzato** 1. Effettua l'autenticazione con le tue credenziali AWS di sicurezza. Questa chiamata deve essere effettuata utilizzando le credenziali di sicurezza AWS . 1. Chiama [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html)l'operazione. L'esempio seguente mostra una richiesta di esempio e la risposta utilizzando `AssumeRole`. Questa richiesta di esempio assume il ruolo `demo` per la durata specificata, inclusi [policy di sessione](access_policies.md#policies_session), [tag di sessione](id_session-tags.md), [ID esterno](id_roles_common-scenarios_third-party.md) e [identità di origine](id_credentials_temp_control-access_monitor.md). La sessione risultante è denominata `John-session`. **Example Richiesta di esempio** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=AssumeRole &RoleSessionName=John-session &RoleArn=arn:aws::iam::123456789012:role/demo &Policy=%7B%22Version%22%3A%222012-10-17 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D &DurationSeconds=1800 &Tags.member.1.Key=Project &Tags.member.1.Value=Pegasus &Tags.member.2.Key=Cost-Center &Tags.member.2.Value=12345 &ExternalId=123ABC &SourceIdentity=DevUser123 &AUTHPARAMS ``` Il valore della policy illustrato nell'esempio precedente è la versione di codifica URL della policy seguente: ------ #### [ JSON ] **** ``` {"Version":"2012-10-17", "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]} ``` ------ Il parametro `AUTHPARAMS` nell'esempio è un segnaposto per la propria *firma*. Una firma è l'informazione di autenticazione che devi includere nelle richieste API AWS HTTP. Ti consigliamo di utilizzarla [AWS SDKs](https://aws.amazon.com/tools/)per creare richieste API e uno dei vantaggi di questa operazione è che SDKs gestirà la firma delle richieste al posto tuo. Se devi creare e firmare le richieste API manualmente, consulta [Firmare AWS le richieste utilizzando la versione 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) della *Riferimenti generali di Amazon Web Services*pagina per scoprire come firmare una richiesta. Oltre alle credenziali di sicurezza temporanee, la risposta include l'Amazon Resource Name (ARN) per l'utente federato e il periodo di scadenza delle credenziali. **Example Esempio di risposta** ``` DevUser123 AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU 9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA== wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2019-07-15T23:28:33.359Z AKIAIOSFODNN7EXAMPLE arn:aws:sts::123456789012:assumed-role/demo/John ARO123EXAMPLE123:John 8 c6104cbe-af31-11e0-8154-cbc7ccf896c7 ``` **Nota** Una AWS conversione comprime le politiche di sessione e i tag di sessione passati in un formato binario compresso con un limite separato. La richiesta può non essere eseguita correttamente a causa di questo limite anche se il testo in chiaro soddisfa gli altri requisiti. L'elemento della risposta `PackedPolicySize` indica in percentuale la consistenza di policy e tag della richiesta rispetto al limite di dimensione superiore. ## Richiesta di credenziali tramite un provider OIDC L'operazione API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) restituisce un set di credenziali di sicurezza AWS temporanee in cambio di un JSON Web Token (JWT). Ciò include provider di identità pubblici, come Login with Amazon, Facebook, Google, e provider JWTs che rilasciano problemi compatibili con il rilevamento di OpenID Connect (OIDC), come GitHub actions o Azure Devops. Per ulteriori informazioni, consulta [Federazione OIDC](id_roles_providers_oidc.md). **Nota** Le richieste `AssumeRoleWithWebIdentity` non sono firmate e non richiedono credenziali AWS . **Richiesta di credenziali tramite un provider OIDC** 1. Chiama [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)l'operazione. Quando chiami`AssumeRoleWithWebIdentity`, AWS convalida il token presentato verificando la firma digitale utilizzando le chiavi pubbliche rese disponibili tramite il keyset web JSON (JWKS) del tuo IdP. Se il token è valido e tutte le condizioni stabilite nella policy di fiducia dei ruoli IAM sono soddisfatte, AWS ti restituisce le seguenti informazioni: + Un set di credenziali di sicurezza temporanee. Consistono in un ID chiave di accesso, in una Secret Access Key e in un token di sessione. + l'ID del ruolo e l'ARN del ruolo assunto. + Un valore `SubjectFromWebIdentityToken` che contiene l'ID utente univoco. 1. L'applicazione può quindi utilizzare le credenziali di sicurezza temporanee restituite nella risposta alle chiamate AWS API. Si tratta dello stesso processo utilizzato per effettuare una chiamata AWS API con credenziali di sicurezza a lungo termine. La differenza è che è necessario includere il token di sessione, che consente di AWS verificare che le credenziali di sicurezza temporanee siano valide. L'applicazione deve memorizzare nella cache le credenziali restituite da AWS STS e aggiornarle secondo necessità. Se l'applicazione è stata creata utilizzando un AWS SDK, l'SDK dispone di provider di credenziali in grado di gestire le chiamate `AssumeRoleWithWebIdentity` e l'aggiornamento AWS delle credenziali prima della scadenza. *Per ulteriori informazioni, consulta i provider di [credenziali standardizzati AWS SDKs e Tools](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html) nella Guida di riferimento agli strumenti.AWS SDKs * ## Richiesta di credenziali tramite un gestore di identità SAML 2.0 L’operazione API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) restituisce un set di credenziali di sicurezza temporanee per i principali federati SAML che sono autenticati dal sistema di identità esistente dell’organizzazione. Gli utenti devono utilizzare inoltre [SAML](https://www.oasis-open.org/standards#samlv2.0) 2.0 (Security Assertion Markup Language) per inoltrare le informazioni di autenticazione e autorizzazione ad AWS. Questa operazione di API è utile in organizzazioni che hanno integrato i propri sistemi di identità (ad esempio Windows Active Directory o OpenLDAP) con software che è in grado di produrre asserzioni SAML. Tale integrazione fornisce informazioni sulle autorizzazioni e identità dell'utente (ad esempio Active Directory Federation Services o Shibboleth). Per ulteriori informazioni, consulta [Federazione SAML 2.0](id_roles_providers_saml.md). 1. Chiama [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)l'operazione. Si tratta di una chiamata non firmata, il che significa che non è necessario autenticare le credenziali di AWS sicurezza prima di effettuare la richiesta. **Nota** Una chiamata a `AssumeRoleWithSAML` non è firmata (crittografata). Pertanto, è opportuno includere le policy di sessione facoltative solo se la richiesta viene trasmessa attraverso un intermediario affidabile. In questo caso, qualcuno potrebbe modificare la policy per rimuovere le limitazioni. 1. Quando chiami`AssumeRoleWithSAML`, AWS verifica l'autenticità dell'asserzione SAML. Supponendo che il provider di identità convalidi l'asserzione, AWS ti restituisce le seguenti informazioni: + Un set di credenziali di sicurezza temporanee. Consistono in un ID chiave di accesso, in una Secret Access Key e in un token di sessione. + l'ID del ruolo e l'ARN del ruolo assunto. + Un valore `Audience` che contiene il valore dell'attributo `Recipient` dell'elemento `SubjectConfirmationData` dell'asserzione SAML. + Un valore `Issuer` che contiene il valore dell'attributo `Issuer` dell'elemento dell'asserzione SAML. + Un `NameQualifier` elemento che contiene un valore hash creato a partire dal `Issuer` valore, dall' Account AWS ID e dal nome descrittivo del provider SAML. In combinazione con l’elemento `Subject`, permette di identificare in modo univoco il principale federato SAML. + Un elemento `Subject` che contiene il valore dell'elemento `NameID` nell'elemento `Subject` dell'asserzione SAML. + Un elemento `SubjectType` che indica il formato dell'elemento `Subject`. Il valore può essere `persistent`, `transient` o il pieno `Format` URI dagli elementi `Subject` e `NameID` utilizzati nell'asserzione SAML. Per ulteriori informazioni sull'attributo `Format` dell'elemento `NameID`, consulta [Configurare le asserzioni SAML per la risposta di autenticazione](id_roles_providers_create_saml_assertions.md). 1. Utilizza le credenziali di sicurezza temporanee restituite nella risposta per effettuare AWS chiamate API. Questa è la stessa procedura utilizzata per effettuare una chiamata AWS API con credenziali di sicurezza a lungo termine. La differenza è che è necessario includere il token della sessione, che consente ad AWS di verificare che le credenziali di sicurezza provvisorie siano valide. L'app deve memorizzare le credenziali. Come impostazione predefinita, le credenziali scadono dopo un'ora. Se non utilizzi l'azione [Amazon STSCredentials Provider](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) nell' AWS SDK, spetta a te e alla tua app effettuare `AssumeRoleWithSAML` nuovamente la chiamata. Chiamare questa operazione per ottenere un nuovo set di credenziali di sicurezza provvisorie prima che i vecchi scadere. ## Richiesta di credenziali tramite un gestore di identità personalizzato L'operazione [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API restituisce un set di credenziali di sicurezza temporanee per i principali utenti AWS STS federati. Questa API differisce da `AssumeRole` per il fatto che il periodo di scadenza predefinito è notevolmente più lungo (12 ore invece di un'ora). Inoltre, è possibile utilizzare il parametro `DurationSeconds` per specificare una durata per le credenziali di sicurezza temporanee perché rimanga valido. Le credenziali risultanti sono valide per la durata specificata, da 900 secondi (15 minuti) a un massimo di 129.600 secondi (36 ore). Il periodo di scadenza più lungo può aiutare a ridurre il numero di chiamate AWS perché non è necessario ottenere nuove credenziali con la stessa frequenza. 1. Effettua l'autenticazione con le credenziali di AWS sicurezza del tuo utente IAM specifico. Questa chiamata deve essere effettuata utilizzando credenziali di AWS sicurezza valide. 1. Chiama [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)l'operazione. La chiamata `GetFederationToken` restituisce le credenziali di sicurezza temporanee che consistono nel token di sessione, nella chiave di accesso, nella chiave segreta e nella scadenza. È possibile utilizzare `GetFederationToken` se si desidera gestire le autorizzazioni nella propria organizzazione (ad esempio, utilizzando l'applicazione proxy per assegnare le autorizzazioni). L'esempio seguente mostra una richiesta di esempio e la risposta che utilizza `GetFederationToken`. Questa richiesta di esempio consente di federare l'utente chiamante per la durata specificata tramite l'ARN della [policy di sessione](access_policies.md#policies_session) e i [tag di sessione](id_session-tags.md). La sessione risultante è denominata `Jane-session`. **Example Richiesta di esempio** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetFederationToken &Name=Jane-session &PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy &DurationSeconds=1800 &Tags.member.1.Key=Project &Tags.member.1.Value=Pegasus &Tags.member.2.Key=Cost-Center &Tags.member.2.Value=12345 &AUTHPARAMS ``` L'ARN della policy illustrato nell'esempio precedente include i seguenti ARN URL-encoded: `arn:aws:iam::123456789012:policy/Role1policy` Inoltre, si noti che il parametro `&AUTHPARAMS` nell'esempio è inteso come segnaposto per le informazioni di autenticazione. Questa è la *firma*, che devi includere nelle richieste API AWS HTTP. Ti consigliamo di utilizzarla [AWS SDKs](https://aws.amazon.com/tools/)per creare richieste API e uno dei vantaggi di questa operazione è che SDKs gestirà la firma delle richieste al posto tuo. Se devi creare e firmare le richieste API manualmente, vai a [Firmare AWS le richieste utilizzando la versione 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) della pagina *Riferimenti generali di Amazon Web Services*per scoprire come firmare una richiesta. Oltre alle credenziali di sicurezza temporanee, la risposta include l'Amazon Resource Name (ARN) per l'utente federato e il periodo di scadenza delle credenziali. **Example Esempio di risposta** ``` AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU 9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE== wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2019-04-15T23:28:33.359Z AKIAIOSFODNN7EXAMPLE; arn:aws:sts::123456789012:federated-user/Jean 123456789012:Jean 4 c6104cbe-af31-11e0-8154-cbc7ccf896c7 ``` **Nota** Una AWS conversione comprime le politiche di sessione e i tag di sessione passati in un formato binario compresso con un limite separato. La richiesta può non essere eseguita correttamente a causa di questo limite anche se il testo in chiaro soddisfa gli altri requisiti. L'elemento della risposta `PackedPolicySize` indica in percentuale la consistenza di policy e tag della richiesta rispetto al limite di dimensione superiore. AWS consiglia di concedere le autorizzazioni a livello di risorsa (ad esempio, si allega una policy basata sulle risorse a un bucket Amazon S3), è possibile omettere il parametro. `Policy` Tuttavia, se non includi una policy per il principale utente AWS STS federato, le credenziali di sicurezza temporanee non concederanno alcuna autorizzazione. In questo caso, è *necessario* utilizzare le policy delle risorse per concedere all'utente federato l'accesso alle risorse AWS . Ad esempio, supponiamo che il tuo Account AWS numero sia 111122223333 e che tu disponga di un bucket Amazon S3 a cui desideri consentire l'accesso a Susan. Le credenziali di sicurezza temporanee di Susan non includono una policy per il bucket. In questo caso, è necessario accertarsi che il bucket disponga di una policy con un ARN corrisponda all'ARN di Susan, ad esempio `arn:aws:sts::111122223333:federated-user/Susan`. ## Richiesta di credenziali per gli utenti in ambienti non attendibili L’operazione API [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) restituisce un set di credenziali di sicurezza temporanee a un utente IAM esistente. Ciò è utile per fornire una maggiore sicurezza, ad esempio consentire le AWS richieste solo quando l'MFA è abilitata per l'utente IAM. Poiché le credenziali sono temporanee, forniscono maggiore sicurezza quando hai un utente IAM che accede alle risorse tramite un ambiente meno sicuro. Esempi di ambienti meno protetti includono dispositivi mobili o browser web. 1. Effettua l'autenticazione con le credenziali di AWS sicurezza del tuo utente IAM specifico. Questa chiamata deve essere effettuata utilizzando credenziali di AWS sicurezza valide. 1. Chiama [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html)l'operazione. 1. `GetSessionToken` restituisce le credenziali di sicurezza temporanee, ossia un token di sessione, l'ID chiave di accesso e una chiave di accesso segreta. Per impostazione predefinita, le credenziali di sicurezza temporanee per un utente IAM sono valide per un massimo di 12 ore. Tuttavia, è possibile richiedere una durata di soli 15 minuti o fino a 36 ore utilizzando il parametro `DurationSeconds`. Per motivi di sicurezza, un token per un Utente root dell'account AWS è limitato a una durata di un'ora. L'esempio seguente mostra una richiesta di esempio e la risposta utilizzando `GetSessionToken`. La risposta include inoltre il periodo di scadenza delle credenziali di sicurezza temporanee. **Example Richiesta di esempio** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetSessionToken &DurationSeconds=1800 &AUTHPARAMS ``` Il parametro `AUTHPARAMS` nell'esempio è un segnaposto per la propria *firma*. Una firma è l'informazione di autenticazione che è necessario includere nelle richieste API AWS HTTP. Ti consigliamo di utilizzarla [AWS SDKs](https://aws.amazon.com/tools/)per creare richieste API e uno dei vantaggi di questa operazione è che SDKs gestirà la firma delle richieste al posto tuo. Se devi creare e firmare le richieste API manualmente, vai a [Firmare AWS le richieste utilizzando la versione 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) della pagina *Riferimenti generali di Amazon Web Services*per scoprire come firmare una richiesta. **Example Esempio di risposta** ``` AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2011-07-11T19:55:29.611Z AKIAIOSFODNN7EXAMPLE 58c5dbae-abef-11e0-8cfe-09039844ac7d ``` Facoltativamente, la `GetSessionToken` richiesta può includere `TokenCode` valori per `SerialNumber` la verifica dell' AWS autenticazione a più fattori (MFA). Se i valori forniti sono validi, AWS STS fornisce credenziali di sicurezza temporanee che includono lo stato dell'autenticazione MFA. Le credenziali di sicurezza temporanee possono quindi essere utilizzate per accedere alle operazioni o ai AWS siti Web dell'API protetti da MFA finché l'autenticazione MFA è valida. L'esempio seguente mostra una richiesta `GetSessionToken`, che include un codice di verifica MFA e il numero di serie del dispositivo. ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetSessionToken &DurationSeconds=7200 &SerialNumber=YourMFADeviceSerialNumber &TokenCode=123456 &AUTHPARAMS ``` **Nota** La chiamata a AWS STS può essere diretta all'endpoint globale o a uno qualsiasi degli endpoint regionali su cui attivi. Account AWS Per ulteriori informazioni, consulta la [sezione di AWS STS relativa alle *regioni e agli endpoint*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region). Il parametro `AUTHPARAMS` nell'esempio è un segnaposto per la propria *firma*. Una firma è l'informazione di autenticazione che devi includere nelle richieste API AWS HTTP. Ti consigliamo di utilizzarla [AWS SDKs](https://aws.amazon.com/tools/)per creare richieste API e uno dei vantaggi di questa operazione è che SDKs gestirà la firma delle richieste al posto tuo. Se devi creare e firmare le richieste API manualmente, consulta [Firmare AWS le richieste utilizzando la versione 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) della *Riferimenti generali di Amazon Web Services*pagina per scoprire come firmare una richiesta. # Usa credenziali temporanee con le risorse AWS Puoi utilizzare credenziali di sicurezza temporanee per effettuare richieste programmatiche di AWS risorse utilizzando l' AWS API AWS CLI o (utilizzando la). [AWS SDKs](https://aws.amazon.com/tools/) Le credenziali temporanee forniscono le stesse autorizzazioni delle credenziali di sicurezza a lungo termine, come ad esempio le credenziali degli utenti IAM. Tuttavia, ci sono alcune differenze: + Quando si effettua una chiamata utilizzando credenziali di sicurezza temporanee, la chiamata deve includere un token di sessione, che viene restituito insieme a tali credenziali temporanee. AWS utilizza il token di sessione per convalidare le credenziali di sicurezza temporanee. + Le credenziali temporanee scadono dopo un intervallo di tempo specificato. Dopo che le credenziali temporanee scadono, tutte le chiamate effettuate con tali credenziali verranno respinte, pertanto dovrai generare un nuovo set di credenziali temporanee. Le credenziali temporanee non possono essere prorogate o aggiornate oltre l'intervallo specificato in origine. + Quando si utilizzano credenziali temporanee per effettuare una richiesta, l'entità potrebbe includere un set di tag. Questi tag provengono da tag di sessione e tag associati al ruolo assunto. Per ulteriori informazioni sui tag di sessione, consultare [Passa i tag di sessione AWS STS](id_session-tags.md). Se si utilizza il [AWS SDKs](https://aws.amazon.com/tools), the [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/)(AWS CLI) o [gli strumenti per Windows PowerShell, il modo per](https://aws.amazon.com/powershell) ottenere e utilizzare le credenziali di sicurezza temporanee varia a seconda del contesto. Se esegui codice o PowerShell comandi Tools for Windows all'interno di un'istanza EC2, puoi sfruttare i ruoli per Amazon EC2. AWS CLI Altrimenti, puoi richiamare un'[API AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/) per ottenere le credenziali provvisorie e utilizzarle in modo esplicito per effettuare chiamate ai servizi AWS . **Nota** 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 risorse. AWS Per ulteriori informazioni su AWS STS, vedere[Credenziali di sicurezza temporanee in IAM](id_credentials_temp.md). AWS STS è un servizio globale con un endpoint predefinito in`https://sts.amazonaws.com`. Questo endpoint si trova nella regione Stati Uniti orientali (Virginia settentrionale), sebbene le credenziali ottenute da questo e da altri endpoint siano valide a livello globale. Queste credenziali funzionano con servizi e risorse in qualsiasi regione. Puoi anche scegliere di effettuare chiamate AWS STS API verso gli endpoint in una qualsiasi delle regioni supportate. Ciò può ridurre la latenza effettuando le richieste da server in una regione geograficamente più vicina a te. Indipendentemente dalla regione dalla quale provengono, le credenziali funzionano a livello globale. Per ulteriori informazioni, consulta [Gestisci AWS STS in un Regione AWS](id_credentials_temp_enable-regions.md). **Contents** + [ ## Utilizzo delle credenziali temporanee nelle istanze Amazon EC2 ](#using-temp-creds-sdk-ec2-instances) + [ ## Utilizzo di credenziali di sicurezza temporanee con AWS SDKs ](#using-temp-creds-sdk) + [ ## Utilizzo di credenziali di sicurezza temporanee con AWS CLI ](#using-temp-creds-sdk-cli) + [ ## Utilizzo delle credenziali di sicurezza temporanee con le operazioni API ](#RequestWithSTS) + [ ## Ulteriori informazioni ](#using-temp-creds-more-info) ## Utilizzo delle credenziali temporanee nelle istanze Amazon EC2 Se desideri eseguire AWS CLI comandi o codice all'interno di un'istanza EC2, il metodo consigliato per ottenere le credenziali consiste nell'utilizzare [i ruoli per Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html). È possibile creare un ruolo IAM che specifichi le autorizzazioni che si desidera concedere alle applicazioni che vengono eseguite sulle istanze EC2. Quando si avvia l'istanza, si associa il ruolo all'istanza. Le applicazioni e AWS CLI i PowerShell comandi Tools for Windows eseguiti sull'istanza possono quindi ottenere credenziali di sicurezza temporanee automatiche dai metadati dell'istanza. Non è necessario ottenere esplicitamente le credenziali di sicurezza temporanee. I AWS SDKs AWS CLI, e Tools for Windows ottengono PowerShell automaticamente le credenziali dall'EC2 Instance Metadata Service (IMDS) e le utilizzano. Le credenziali temporanee hanno le autorizzazioni che si definiscono per il ruolo associato all'istanza. Per maggiori informazioni ed esempi, consultare quanto segue: + [Utilizzo dei ruoli IAM per concedere l'accesso alle AWS risorse su Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) — AWS SDK per Java + [Concessione dell'accesso utilizzando un ruolo IAM](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) — AWS SDK per .NET + [Creazione di un ruolo](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html): AWS SDK per Ruby ## Utilizzo di credenziali di sicurezza temporanee con AWS SDKs Per utilizzare credenziali di sicurezza temporanee nel codice, chiamate a livello di codice un' AWS STS API simile a un'API `AssumeRole` ed estraete le credenziali e il token di sessione risultanti. Questi valori vengono quindi utilizzati come credenziali per le chiamate successive a. AWS L'esempio seguente mostra lo pseudocodice su come utilizzare le credenziali di sicurezza temporanee se utilizzi un SDK: AWS ``` assumeRoleResult = AssumeRole(role-arn); tempCredentials = new SessionAWSCredentials( assumeRoleResult.AccessKeyId, assumeRoleResult.SecretAccessKey, assumeRoleResult.SessionToken); s3Request = CreateAmazonS3Client(tempCredentials); ``` Per un esempio scritto in Python (usando [AWS SDK per Python (Boto)](https://aws.amazon.com/sdk-for-python/)), consultare [Passa a un ruolo IAM (AWS API)](id_roles_use_switch-role-api.md). In questo esempio viene illustrato come richiamare `AssumeRole` per ottenere le credenziali di sicurezza temporanee e quindi utilizzare tali credenziali per effettuare una chiamata ad Amazon S3. Per dettagli su come richiamare `AssumeRole`, `GetFederationToken` e altre operazioni API, consulta la [Documentazione di riferimento delle API AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/). Per informazioni su come ottenere le credenziali di sicurezza provvisorie e il token di sessione dal risultato, consulta la documentazione dell'SDK in uso. **Puoi trovare la documentazione per tutti nella [pagina di AWS documentazione](https://aws.amazon.com/documentation) principale, nella sezione e Toolkits. AWS SDKs SDKs ** È necessario accertarsi che sia possibile ottenere un nuovo set di credenziali prima della scadenza. In alcuni SDKs, puoi utilizzare un provider che gestisca il processo di aggiornamento delle credenziali al tuo posto; consulta la documentazione dell'SDK che stai utilizzando. ## Utilizzo di credenziali di sicurezza temporanee con AWS CLI È possibile utilizzare le credenziali di sicurezza temporanee con AWS CLI Questo può essere utile per testare le policy. Tramite la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/), puoi richiamare un'[API AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/) come `AssumeRole` o `GetFederationToken` e acquisire l'output risultante. L'esempio seguente mostra una chiamata a `AssumeRole` che invia l'output a un file. Nell'esempio, si presume che il `profile` parametro sia un profilo nel file di AWS CLI configurazione. Si presume inoltre di fare riferimento alle credenziali di un utente IAM che disponga delle autorizzazioni per assumere il ruolo. ``` aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt ``` Quando il comando viene completato, è possibile estrarre l'ID della chiave di accesso, la chiave di accesso segreta e il token di sessione da qualunque posto sia stato instradato. È possibile farlo manualmente o utilizzando uno script. È possibile assegnare questi valori alle variabili di ambiente. Quando AWS CLI esegui i comandi, AWS CLI cerca le credenziali in un ordine specifico, prima nelle variabili di ambiente e poi nel file di configurazione. Pertanto, dopo aver inserito le credenziali temporanee nelle variabili di ambiente, AWS CLI utilizza tali credenziali per impostazione predefinita. (Se specificate un `profile` parametro nel comando, AWS CLI salta le variabili di ambiente. Al contrario, viene AWS CLI visualizzato nel file di configurazione, che consente di sovrascrivere le credenziali nelle variabili di ambiente, se necessario.) L'esempio seguente mostra come impostare le variabili di ambiente per le credenziali di sicurezza temporanee e quindi chiamare un comando. AWS CLI Poiché nel AWS CLI comando non è incluso alcun `profile` parametro, AWS CLI cerca le credenziali prima nelle variabili di ambiente e quindi utilizza le credenziali temporanee. **Linux** ``` $ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE $ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY $ export AWS_SESSION_TOKEN=AQoDYXdzEJr... $ aws ec2 describe-instances --region us-west-1 ``` **Windows** ``` C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr... C:\> aws ec2 describe-instances --region us-west-1 ``` ## Utilizzo delle credenziali di sicurezza temporanee con le operazioni API Se stai effettuando richieste API HTTPS dirette a AWS, puoi firmare tali richieste con le credenziali di sicurezza temporanee che ottieni da (). AWS Security Token Service AWS STS A tale scopo, utilizzate l'ID della chiave di accesso e la chiave di accesso segreta da AWS STS cui ricevete. Utilizzare l'ID della chiave di accesso e la chiave di accesso segreta nello stesso modo in cui si utilizzano le credenziali a lungo termine per firmare una richiesta. Inoltre, aggiungi alla tua richiesta API il token di sessione da cui ricevi AWS STS. Aggiungere il token della sessione a un'intestazione HTTP o a un parametro della stringa di query denominato `X-Amz-Security-Token`. Aggiungi il token di sessione all'intestazione HTTP *o* il parametro della stringa di query, ma non entrambi. Per ulteriori informazioni sulla firma delle richieste API HTTPS, consulta [Firmare le richieste AWS API](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html) in *Riferimenti generali di AWS*. ## Ulteriori informazioni Per ulteriori informazioni sull'utilizzo AWS STS con altri AWS servizi, consulta i seguenti collegamenti: + **Amazon S3**. Consulta [Esecuzione di richieste mediante le credenziali temporanee per gli utenti IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html) o [Esecuzione di richieste mediante le credenziali temporanee per gli utenti federati](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html) nella *Guida per l'utente di Amazon Simple Storage Service*. + **Amazon SNS** Consulta [Utilizzo di policy basate su identità con Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS) nella *Guida per gli sviluppatori di Amazon Simple Notification Service*. + **Amazon SQS** Consulta [Identity and Access Management in Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS) nella *Guida per gli sviluppatori di Amazon Simple Queue Service* + **Amazon SimpleDB** Consulta [Utilizzo di credenziali di sicurezza temporanee](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html) nella *Guida per gli sviluppatori di Amazon SimpleDB*. # 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" } ] } ``` ------ # Gestisci AWS STS in un Regione AWS Un endpoint regionale è l'URL del punto di ingresso all'interno di una particolare regione per un servizio AWS Web. AWS consiglia di utilizzare gli endpoint Regional AWS Security Token Service (AWS STS) anziché l'endpoint globale per ridurre la latenza, aumentare la ridondanza e aumentare la validità dei token di sessione. Sebbene l' AWS STS endpoint globale (legacy) sia altamente disponibile, `https://sts.amazonaws.com` è ospitato in un'unica AWS regione, Stati Uniti orientali (Virginia settentrionale) e, come altri endpoint, non fornisce il failover automatico sugli endpoint di altre regioni. + **Riduzione della latenza**: effettuando AWS STS chiamate verso un endpoint geograficamente più vicino ai servizi e alle applicazioni, è possibile accedere AWS STS a servizi con una latenza inferiore e tempi di risposta migliori. + **Progetta in ridondanza**: puoi limitare gli effetti di un guasto all'interno di un carico di lavoro a un numero limitato di componenti con un ambito prevedibile di contenimento degli impatti. L'utilizzo AWS STS degli endpoint regionali consente di allineare l'ambito dei componenti con quello dei token di sessione. Per ulteriori informazioni su questo pilastro di affidabilità, consulta [Uso dell'isolamento dei guasti per proteggere il carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) in *Framework AWS  Well-Architected*. + **Aumenta la validità dei token** di sessione: i token di sessione degli AWS STS endpoint regionali sono validi in tutti. Regioni AWS I token di sessione dell'endpoint STS globale sono validi solo se sono abilitati per Regioni AWS impostazione predefinita. Se intendi abilitare una nuova regione per il tuo account, puoi utilizzare i token di sessione dagli endpoint regionali. AWS STS Se scegli di utilizzare l'endpoint globale, devi modificare la compatibilità regionale dei token di AWS STS sessione per l'endpoint globale. In questo modo si garantisce che i token siano validi in tutti. Regioni AWS Per un elenco delle AWS STS regioni e dei relativi endpoint, consulta. [AWS STS Regioni ed endpoint](id_credentials_temp_region-endpoints.md) **Nota** AWS ha apportato modifiche all'endpoint globale AWS Security Token Service (AWS STS`https://sts.amazonaws.com`) nelle Regioni [abilitate di default](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) per migliorarne la resilienza e le prestazioni. AWS STS le richieste all'endpoint globale vengono servite automaticamente nello stesso Regione AWS modo in cui vengono servite i tuoi carichi di lavoro. Queste modifiche non verranno implementate nelle Regioni con attivazione facoltativa. Ti consigliamo di utilizzare gli endpoint AWS STS regionali appropriati. Per ulteriori informazioni, consulta [AWS STS cambiamenti globali degli endpoint](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes). **Topics** + [ ## Attivazione e disattivazione in un AWS STS Regione AWS ](#sts-regions-activate-deactivate) + [ ## Scrittura di codice per utilizzare le regioni AWS STS ](#id_credentials_temp_enable-regions_writing_code) + [ ## Gestione dei token di sessione emessi dall'endpoint globale ](#sts-regions-manage-tokens) ## Attivazione e disattivazione in un AWS STS Regione AWS Quando attivi gli AWS STS endpoint per una regione, AWS STS puoi emettere credenziali temporanee agli utenti e ai ruoli del tuo account che effettuano una richiesta. AWS STS Queste credenziali possono essere utilizzate in qualsiasi regione abilitata di default o manualmente. Per le regioni abilitate per impostazione predefinita, è necessario attivare l' AWS STS endpoint regionale nell'account in cui vengono generate le credenziali temporanee. Al momento di effettuare la richiesta, non importa se un utente è autenticato sullo stesso account o su un altro account. Quando si richiedono credenziali temporanee per un ruolo in un altro Account AWS utilizzando una regione abilitata manualmente, l'account di destinazione (l'account contenente il ruolo) deve abilitare tale regione per le operazioni. AWS STS Ciò garantisce che le credenziali di sicurezza temporanee possano essere generate correttamente. Immagina, ad esempio, che un utente nell’account A desideri inviare una richiesta API `sts:AssumeRole` all’[endpoint regionale AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) `https://sts.ap-southeast-3.amazonaws.com`. La richiesta si riferisce a delle credenziali temporanee per il ruolo denominato `Developer` nell’account B. Poiché la richiesta è di creare le credenziali per un’entità nell’account B, l’account B deve avere la Regione `ap-southeast-3` abilitata. Gli utenti dell'account A (o di qualsiasi altro account) possono chiamare l'endpoint `ap-southeast-3` AWS STS per richiedere le credenziali per l'account B, che la regione sia attivata o meno nel loro account. Per ulteriori informazioni, consulta [Abilita o disabilita Regioni AWS nel tuo account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html). **Nota** Le regioni attive sono disponibili per tutti gli utenti che utilizzano credenziali provvisorie in tale account. Per controllare quali utenti o ruoli IAM possono accedere alla regione, utilizza la chiave di condizione `aws:RequestedRegion` nelle tue policy di autorizzazione. **Per attivarlo o disattivarlo AWS STS in una regione abilitata per impostazione predefinita (console)** 1. Accedi come utente root o come utente con le autorizzazioni per eseguire attività di amministrazione di IAM. 1. Apri la [console IAM](https://console.aws.amazon.com/iam/home?#home) e, nel pannello di navigazione, seleziona [https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings). 1. Nella sezione **Endpoint** di **Security Token Service (STS)**, trova la Regione che desideri configurare, quindi scegli **Attiva** o **Inattiva** nella colonna **Stato STS**. 1. Nella finestra di dialogo visualizzata, scegli **Activate** (Attiva) o **Deactivate** (Disattiva). Per le regioni che devono essere abilitate, ci attiviamo AWS STS automaticamente quando abiliti la regione. Dopo aver abilitato una regione, AWS STS è sempre attiva per la regione e non è possibile disattivarla. Per ulteriori informazioni sull'attivazione delle aree che sono disabilitate per impostazione predefinita, consulta [Specificazione delle aree che Regioni AWS il proprio account può utilizzare](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) nella Guida *Gestione dell'account AWS di riferimento*. ## Scrittura di codice per utilizzare le regioni AWS STS Dopo aver attivato una regione, puoi indirizzare le chiamate AWS STS API verso quella regione. Il frammento di codice Java seguente mostra come configurare un oggetto `AWSSecurityTokenService` affinché effettui richieste alla regione Europa (Milano) (eu-south-1). ``` EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1"); AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard() .withCredentials(credentials) .withEndpointConfiguration(regionEndpointConfig) .build(); ``` AWS STS consiglia di effettuare chiamate verso un endpoint regionale. Per scoprire come abilitare manualmente una regione, consulta [Specificare le Regioni AWS che il tuo account può utilizzare](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) nella *Guida di riferimento a Gestione dell'account AWS *. Nell'esempio, la prima riga crea un'istanza di un oggetto `EndpointConfiguration` chiamata `regionEndpointConfig`, passando l'URL dell'endpoint e la Regione AWS come parametri. *Per informazioni su come impostare gli endpoint AWS STS regionali utilizzando una variabile di ambiente per AWS SDKs, consulta [Endpoint AWS STS regionalizzati](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) nella and Tools Reference Guide.AWS SDKs * Per tutte le altre combinazioni di linguaggio e ambiente di programmazione, consulta la [documentazione dell'SDK pertinente](https://aws.amazon.com/tools/). ## Gestione dei token di sessione emessi dall'endpoint globale Per impostazione predefinita, la Regioni AWS maggior parte di esse è abilitata al funzionamento. Servizi AWS Queste regioni vengono attivate automaticamente per essere utilizzate con AWS STS. Alcune regioni, ad esempio Asia Pacifico (Hong Kong), devono essere abilitate manualmente. Per ulteriori informazioni sull'abilitazione e la disabilitazione di Regioni AWS, consulta [Specificare le Regioni AWS che il tuo account può utilizzare](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) nella *Guida di riferimento a Gestione dell'account AWS *. Quando si abilitano queste AWS regioni, vengono automaticamente attivate per l'uso con AWS STS. Non è possibile attivare l' AWS STS endpoint per una regione disattivata. I token di sessione validi in tutte le aree Regioni AWS includono più caratteri rispetto ai token validi nelle regioni abilitate per impostazione predefinita. La modifica di questa impostazione potrebbe influenzare i sistemi esistenti in cui vengono memorizzati temporaneamente i token. È possibile modificare questa impostazione utilizzando l'API Console di gestione AWS, AWS CLI, o AWS . **Modificare le regioni compatibili con i token di sessione l'endpoint globale (console)** 1. Accedi come utente root o come utente con le autorizzazioni per eseguire attività di amministrazione di IAM. Per modificare la compatibilità dei token di sessione, è necessario disporre di una policy che consente l'operazione `iam:SetSecurityTokenServicePreferences`. 1. Apri la [console IAM](https://console.aws.amazon.com/iam/home?#home). Nel riquadro di navigazione, scegliere **Account settings (Impostazioni account)**. 1. Nella sezione **Security Token Service (STS)** **Token di sessione dagli endpoint STS**. L'**endpoint globale** indica `Valid only in Regioni AWS enabled by default`. Scegliere **Change (Cambia)**. 1. Nella finestra di dialogo **Modifica compatibilità dell'area**, seleziona **Tutto Regioni AWS**. Selezionare quindi **Save changes (Salva modifiche)**. **Nota** I token di sessione validi in tutte le aree Regione AWS includono più caratteri rispetto ai token validi nelle regioni abilitate per impostazione predefinita. La modifica di questa impostazione potrebbe influenzare i sistemi esistenti in cui vengono memorizzati temporaneamente i token. **Modificare le regioni compatibili con i token di sessione l'endpoint globale (AWS CLI)** Imposta la versione del token di sessione. I token della versione 1 sono validi solo se sono disponibili per impostazione predefinita. Regioni AWS Questi token non funzionano nelle regioni abilitate manualmente, ad esempio Asia Pacifico (Hong Kong). I token Versione 2 sono validi in tutte le regioni. Tuttavia, i token versione 2 sono composti da un numero maggiore di caratteri e ciò può influire sui sistemi in cui vengono memorizzati temporaneamente i token. + [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html) **Per modificare la compatibilità regionale dei token di sessione per l'endpoint globale (API)AWS** Imposta la versione del token di sessione. I token della versione 1 sono validi solo se sono disponibili per impostazione predefinita. Regioni AWS Questi token non funzionano nelle regioni abilitate manualmente, ad esempio Asia Pacifico (Hong Kong). I token Versione 2 sono validi in tutte le regioni. Tuttavia, i token versione 2 sono composti da un numero maggiore di caratteri e ciò può influire sui sistemi in cui vengono memorizzati temporaneamente i token. + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html) # AWS STS Regioni ed endpoint **Nota** AWS ha apportato modifiche all'endpoint globale AWS Security Token Service (AWS STS`https://sts.amazonaws.com`) nelle Regioni [abilitate di default](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) per migliorarne la resilienza e le prestazioni. AWS STS le richieste all'endpoint globale vengono servite automaticamente Regione AWS come i tuoi carichi di lavoro. Queste modifiche non verranno implementate nelle Regioni con attivazione facoltativa. Ti consigliamo di utilizzare gli endpoint AWS STS regionali appropriati. Per ulteriori informazioni, consulta [AWS STS cambiamenti globali degli endpoint](#reference_sts_global_endpoint_changes). La seguente tabella elenca le regioni e i relativi endpoint. Indica quali sono attivate per default e quali possono essere attivate o disattivate. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) ¹È necessario [abilitare la regione](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) per utilizzarla. Ciò attiva automaticamente AWS STS. Non è possibile attivare o disattivare manualmente AWS STS in queste regioni. ²Per utilizzarlo AWS in Cina, sono necessari un account e credenziali specifici per la AWS Cina. ## AWS STS cambiamenti globali degli endpoint AWS ha apportato modifiche all'endpoint globale AWS Security Token Service (AWS STS`https://sts.amazonaws.com`) nelle Regioni [abilitate di default](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) per migliorarne la resilienza e le prestazioni. In precedenza, tutte le richieste all'endpoint AWS STS globale venivano servite da un unico dispositivo Regione AWS, gli Stati Uniti orientali (Virginia settentrionale). Ora, nelle regioni [abilitate per impostazione predefinita](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html), le richieste all'endpoint AWS STS globale vengono servite automaticamente nella stessa regione da cui proviene la richiesta, anziché nella regione degli Stati Uniti orientali (Virginia settentrionale). Queste modifiche non verranno implementate nelle Regioni con attivazione facoltativa. Con questa modifica, AWS STS elaborerà la richiesta in base alla regione di origine e al resolver DNS utilizzati. Le richieste all'endpoint AWS STS globale vengono servite nella stessa regione del carico di lavoro AWS distribuito se la richiesta DNS per l'endpoint AWS STS globale viene gestita dal server Amazon DNS nelle regioni abilitate per impostazione predefinita. Le richieste all’endpoint globale AWS STS continueranno a essere servite nella Regione Stati Uniti orientali (Virginia settentrionale) se la richiesta proviene da Regioni con attivazione facoltativa o se la richiesta è stata risolta utilizzando un resolver DNS diverso dal server Amazon DNS. Per ulteriori informazioni su Amazon DNS, consulta [Server DNS Amazon](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS) nella *Guida per l’utente di Amazon Virtual Private Cloud*. La tabella seguente mostra come le richieste verso l'endpoint AWS STS globale vengono instradate in base al provider DNS. | Resolver DNS | Le richieste all'endpoint AWS STS globale vengono instradate verso il locale? Regione AWS | | --- | --- | | Resolver DNS Amazon in un Amazon VPC in una Regione abilitata per impostazione predefinita | Sì | | Resolver DNS Amazon in un Amazon VPC in una Regione con attivazione facoltativa | No, la richiesta verrà instradata nella Regione Stati Uniti orientali (Virginia settentrionale) | | Resolver DNS fornito dal tuo ISP, da un provider DNS pubblico o da qualsiasi altro provider DNS | No, la richiesta verrà instradata nella Regione Stati Uniti orientali (Virginia settentrionale) | Per garantire un'interruzione minima dei processi esistenti, AWS ha implementato le seguenti misure: + AWS CloudTrail i registri delle richieste effettuate all'endpoint AWS STS globale vengono inviati nella regione Stati Uniti orientali (Virginia settentrionale). CloudTrail i registri delle richieste servite dagli endpoint AWS STS regionali continueranno a essere registrati nella rispettiva regione. CloudTrail + CloudTrail i registri per le operazioni eseguite dall'endpoint AWS STS globale e dagli endpoint regionali contengono campi aggiuntivi e indicano quale endpoint `endpointType` e `awsServingRegion` regione hanno fornito la richiesta. Per esempi di CloudTrail log, vedere. [Esempio di evento AWS STS API che utilizza l'endpoint globale nel file di registro CloudTrail](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint) + Le richieste effettuate all'endpoint AWS STS globale hanno un valore pari a `us-east-1` for the `aws:RequestedRegion` condition key, indipendentemente dalla regione che ha fornito la richiesta. + Le richieste gestite dall'endpoint AWS STS globale non condividono una quota di richieste al secondo con gli endpoint regionali. AWS STS Se disponi di carichi di lavoro in una regione opzionale e stai ancora utilizzando l'endpoint AWS STS globale, ti consigliamo di effettuare la migrazione agli endpoint AWS STS regionali per migliorare la resilienza e le prestazioni. *Per ulteriori informazioni sulla configurazione degli endpoint regionali, consulta AWS STS Endpoint regionali nella and Tools Reference [AWS STS Guide](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html).AWS SDKs * ## AWS CloudTrail e endpoint regionali Le chiamate agli endpoint regionali e globali vengono registrate sul campo `tlsDetails` in  AWS CloudTrail. Le chiamate verso gli endpoint regionali, ad esempio`us-east-2.amazonaws.com`, vengono registrate nella regione CloudTrail appropriata. Le chiamate all'endpoint globale, `sts.amazonaws.com`, vengono registrate come chiamate a un servizio globale. Gli eventi per gli AWS STS endpoint globali vengono registrati su us-east-1. **Nota** `tlsDetails` può essere visualizzato solo per i servizi che supportano questo campo. *Vedi [i dettagli sui servizi che supportano TLS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html) nella Guida per l'utente CloudTrail AWS CloudTrail * Per ulteriori informazioni, consulta [Registrazione delle chiamate IAM e AWS STS API con AWS CloudTrail](cloudtrail-integration.md). # Abilita l'accesso personalizzato del broker di identità alla AWS console Puoi scrivere ed eseguire codice per creare un URL che permette agli utenti che accedono alla rete dell'organizzazione di accedere in modo sicuro alla Console di gestione AWS. L'URL include un token di accesso che ottieni AWS e che consente di autenticare l'utente. AWS La sessione console risultante potrebbe includere una distinta `AccessKeyId` a causa della federazione. [Per tracciare l'utilizzo delle chiavi di accesso per l'accesso alla federazione tramite CloudTrail eventi correlati, vedi [Registrazione delle chiamate IAM e AWS STS API con AWS CloudTrail](cloudtrail-integration.md) e accedi agli eventi.Console di gestione AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html) **Nota** Se la tua organizzazione usa un provider di identità (IdP) compatibile con SAML, puoi configurare l'accesso alla console senza la necessità di scrivere codice. Ciò è possibile con provider come Microsoft Active Directory Federation Services oppure Shibboleth open source. Per informazioni dettagliate, vedi [Consentire ai principali federati SAML 2.0 di accedere a Console di gestione AWS](id_roles_providers_enable-console-saml.md). Per consentire agli utenti dell'organizzazione di accedere a Console di gestione AWS, è possibile creare un *broker di identità* personalizzato che esegua i seguenti passaggi: 1. Verifica che l'utente sia autenticato dal sistema di identità locale. 1. Chiamate le operazioni AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)(AWS STS) (consigliato) o [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API per ottenere credenziali di sicurezza temporanee per l'utente. Per informazioni sui diversi metodi che si possono utilizzare per assumere un ruolo, consulta [Metodi per assumere un ruolo](id_roles_manage-assume.md). Per informazioni su come passare i tag di sessione facoltativi quando si ottengono le credenziali di sicurezza, consulta [Passa i tag di sessione AWS STS](id_session-tags.md). + Se usi una delle operazioni API `AssumeRole*` per ottenere credenziali di sicurezza temporanee per un ruolo, puoi includere il parametro `DurationSeconds` nella chiamata. Questo parametro specifica la durata della sessione del ruolo, da 900 secondi (15 minuti) fino all'impostazione di durata massima della sessione per il ruolo. Quando si utilizza `DurationSeconds` in un'operazione `AssumeRole*`, è necessario chiamarlo come un utente IAM con credenziali a lungo termine. In caso contrario, la chiamata all'endpoint di federazione nella fase 3 ha esito negativo. Per informazioni su come visualizzare o modificare il valore massimo per un ruolo, consulta [Aggiornamento della durata massima della sessione per un ruolo](id_roles_update-role-settings.md#id_roles_update-session-duration). + Se usi l'operazione API `GetFederationToken` per ottenere le credenziali, puoi includere il parametro `DurationSeconds` nella chiamata. Questo parametro specifica la durata della sessione del ruolo. Il valore può variare da 900 secondi (15 minuti) a 129.600 secondi (36 ore). Puoi effettuare questa chiamata API solo utilizzando le credenziali di AWS sicurezza a lungo termine di un utente IAM. Puoi anche effettuare queste chiamate utilizzando Utente root dell'account AWS le credenziali, ma non è consigliabile. Se effettui la chiamata come utente root, la sessione di default dura un'ora. In alternativa, puoi specificare una sessione con durata compresa tra 900 secondi (15 minuti) e 3.600 secondi (un'ora). 1. Chiama l'endpoint AWS della federazione e fornisci le credenziali di sicurezza temporanee per richiedere un token di accesso. 1. Crea un URL per la console che include il token: + Se usi una delle operazioni API `AssumeRole*` nell'URL, puoi includere il parametro HTTP `SessionDuration`. Questo parametro specifica la durata della sessione della console, da 900 secondi (15 minuti) a 43.200 secondi (12 ore). + Se usi l'operazione API `GetFederationToken` nell'URL, puoi includere il parametro `DurationSeconds`. Questo parametro specifica la durata della sessione della console federata. Il valore può variare da 900 secondi (15 minuti) a 129.600 secondi (36 ore). **Nota** `SessionDuration` non può essere maggiore o uguale alla durata massima della sessione impostata per il ruolo che stai assumendo. Ad esempio, si assuma di aver impostato la durata massima della sessione per il ruolo che desideri assumere su 5 ore. Il parametro `SessionDuration` può essere 16.524 secondi o 4 ore e 59 secondi. Non usare il parametro HTTP `SessionDuration` quando ottieni le credenziali temporanee con `GetFederationToken`. L’operazione avrà esito negativo. L'utilizzo delle credenziali perché un ruolo assuma un ruolo diverso viene chiamato [*concatenamento dei ruoli*](id_roles.md#iam-term-role-chaining). Quando si utilizza il concatenamento dei ruoli, le nuove credenziali sono limitate a una durata massima di un'ora. Quando si utilizzano i ruoli per [concedere autorizzazioni alle applicazioni eseguite su istanze EC2](id_roles_use_switch-role-ec2.md), tali applicazioni non sono soggette a questa limitazione. Non usare il parametro HTTP `SessionDuration` quando ottieni le credenziali temporanee tramite la concatenazione dei ruoli. L’operazione avrà esito negativo. 1. Fornisce l'URL all'utente o richiama l'URL per conto dell'utente. L'URL fornito dall'endpoint di federazione è valido per 15 minuti dopo la creazione. Questo intervallo di tempo è diverso dalla durata (in secondi) della sessione delle credenziali di sicurezza temporanee associata all'URL. Queste credenziali sono valide per la durata specificata al momento della creazione, a partire dal momento in cui sono state create. **Importante** L'URL concede l'accesso alle tue AWS risorse tramite, Console di gestione AWS se hai abilitato le autorizzazioni nelle credenziali di sicurezza temporanee associate. Per questo motivo, devi trattare l'URL come segreto. Ti consigliamo di restituire l'URL attraverso un reindirizzamento sicuro, ad esempio usando un codice di stato della risposta HTTP 302 in una connessione SSL. Per ulteriori informazioni sul codice di stato della risposta HTTP 302, consulta [RFC 2616, sezione 10.3.3](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3). Per completare queste attività, puoi utilizzare l'[API di query HTTPS per AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/APIReference/) e [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/). In alternativa, puoi utilizzare linguaggi di programmazione come Java, Ruby o C \$1 con l'[SDK AWS](https://aws.amazon.com/tools/) appropriato. Ognuno di questi metodi è descritto negli argomenti seguenti. **Topics** + [ ## Codice di esempio per l'uso delle operazioni API di query IAM ](#STSConsoleLink_manual) + [ ## Codice di esempio con Python ](#STSConsoleLink_programPython) + [ ## Esempio di codice con Java ](#STSConsoleLink_programJava) + [ ## Esempio ci creazione dell'URL (Ruby) ](#STSConsoleLink_programRuby) ## Codice di esempio per l'uso delle operazioni API di query IAM Puoi creare un URL che concede ai ruoli e ai principali federati l’accesso diretto alla Console di gestione AWS. Questa attività utilizza le API di interrogazione IAM e AWS STS HTTPS. Per ulteriori informazioni su come effettuare richieste di query, consulta [Effettuare richieste di query](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html). **Nota** La procedura seguente contiene esempi di stringhe di testo. Per migliorare la leggibilità, sono state aggiunte interruzioni di riga in alcuni degli esempi più lunghi. Quando crei queste stringhe per l'uso, ometti le interruzioni di riga. **Per consentire ai ruoli e ai responsabili federati di accedere alle tue risorse dal Console di gestione AWS** 1. Autentica l'utente nel sistema di identità e autorizzazione. 1. Ottieni credenziali di sicurezza temporanee per l'utente. Le credenziali temporanee sono costituite da un ID chiave di accesso, una chiave di accesso segreta e un token di sessione. Per ulteriori informazioni sulla creazione di credenziali temporanee, consulta [Credenziali di sicurezza temporanee in IAM](id_credentials_temp.md). Per ottenere credenziali temporanee, chiamate l' AWS STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API (scelta consigliata) o l'API. [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) Per ulteriori informazioni sulle differenze tra queste operazioni API, consulta [Comprendere le opzioni API per delegare in modo sicuro l'accesso al tuo AWS account nel blog](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account) sulla AWS sicurezza. **Importante** Quando utilizzi l'[GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API per creare credenziali di sicurezza temporanee, devi specificare le autorizzazioni che le credenziali concedono all'utente che assume il ruolo. Per le operazioni API che iniziano con `AssumeRole*`, è necessario usare un ruolo IAM per assegnare le autorizzazioni. Per le altre operazioni API, il meccanismo varia a seconda dell'API. Per ulteriori dettagli, consultare [Autorizzazioni per le credenziali di sicurezza temporanee](id_credentials_temp_control-access.md). Inoltre, se usi le operazioni API `AssumeRole*`, devi chiamarle come utente IAM con credenziali a lungo termine. In caso contrario, la chiamata all'endpoint di federazione nella fase 3 ha esito negativo. 1. Dopo aver ottenuto le credenziali di sicurezza temporanee, integrale in una stringa di sessione JSON per scambiarle con un token di accesso. Nell'esempio seguente viene illustrato come codificare le credenziali. Sostituisci il testo segnaposto con i valori appropriati delle credenziali ricevute nella fase precedente. ``` {"sessionId":"*** temporary access key ID ***", "sessionKey":"*** temporary secret access key ***", "sessionToken":"*** session token ***"} ``` 1. Effettuare la [codifica tramite URL](https://en.wikipedia.org/wiki/Percent-encoding) della stringa di sessione della fase precedente. Poiché le informazioni codificate sono informazioni sensibili, ti consigliamo di evitare l'uso di un servizio Web per la codifica. Usa invece una funzione o una caratteristica installata in locale nel kit di strumenti di sviluppo per codificare queste informazioni in modo sicuro. Puoi usare la funzione `urllib.quote_plus` in Python, la funzione `URLEncoder.encode` in Java o la funzione `CGI.escape` in Ruby. Consulta gli esempi più avanti in questo argomento. 1. **Nota** AWS supporta le richieste POST qui. Invia la tua richiesta all'endpoint della AWS federazione: `https://region-code.signin.aws.amazon.com/federation` Per un elenco dei *region-code* valori possibili, consulta la colonna **Regione** negli endpoint di [AWS accesso](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Facoltativamente, puoi utilizzare l'endpoint federativo di AWS accesso predefinito: `https://signin.aws.amazon.com/federation` La richiesta deve includere i parametri `Action` e `Session` e, facoltativamente, se è stata utilizzata un'operazione API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html), un parametro HTTP `SessionDuration` come illustrato nell'esempio seguente. ``` Action = getSigninToken SessionDuration = time in seconds Session = *** the URL encoded JSON string created in steps 3 & 4 *** ``` **Nota** Le seguenti istruzioni in questa fase funzionano solo con le richieste GET. Il parametro HTTP `SessionDuration` specifica la durata della sessione della console. Si tratta di un valore diverso rispetto alla durata delle credenziali temporanee specificato usando il parametro `DurationSeconds`. Puoi specificare un valore massimo di `SessionDuration` pari a 43.200 (12 ore). Se il `SessionDuration` parametro non è presente, la sessione utilizza per impostazione predefinita la durata delle credenziali recuperate AWS STS nel passaggio 2 (che per impostazione predefinita è un'ora). Consultare la [documentazione per l'API `AssumeRole`](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) per informazioni dettagliate su come specificare una durata tramite il parametro `DurationSeconds`. La possibilità di creare una sessione della console più lunga di un'ora è intrinseca nell'operazione `getSigninToken` dell'endpoint di federazione. **Nota** `SessionDuration` non può essere maggiore o uguale alla durata massima della sessione impostata per il ruolo che stai assumendo. Ad esempio, si assuma di aver impostato la durata massima della sessione per il ruolo che desideri assumere su 5 ore. Il parametro `SessionDuration` può essere 16.524 secondi o 4 ore e 59 secondi. Non usare il parametro HTTP `SessionDuration` quando ottieni le credenziali temporanee con `GetFederationToken`. L’operazione avrà esito negativo. L'utilizzo delle credenziali perché un ruolo assuma un ruolo diverso viene chiamato [*concatenamento dei ruoli*](id_roles.md#iam-term-role-chaining). Quando si utilizza il concatenamento dei ruoli, le nuove credenziali sono limitate a una durata massima di un'ora. Quando si utilizzano i ruoli per [concedere autorizzazioni alle applicazioni eseguite su istanze EC2](id_roles_use_switch-role-ec2.md), tali applicazioni non sono soggette a questa limitazione. Non usare il parametro HTTP `SessionDuration` quando ottieni le credenziali temporanee tramite la concatenazione dei ruoli. L’operazione avrà esito negativo. Quando abiliti le sessioni della console con una durata estesa, aumenti il rischio di esposizione delle credenziali. Per mitigare questo rischio, è possibile disabilitare immediatamente le sessioni della console attive per tutti i ruoli, scegliendo **Revoca sessioni** nella pagina **Riepilogo ruolo** nella console IAM. Per ulteriori informazioni, consulta [Revocare le credenziali di sicurezza temporanee per i ruoli IAM](id_roles_use_revoke-sessions.md). Di seguito è riportato un esempio di richiesta. Per le righe è impostato il ritorno a capo per semplificare la lettura, ma devi inviare la richiesta come stringa su un'unica riga. ``` https://signin.aws.amazon.com/federation ?Action=getSigninToken &SessionDuration=1800 &Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22 %3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2 2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8 FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5 PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D ``` La risposta dell'endpoint di federazione è un documento JSON con un valore `SigninToken`. L'aspetto sarà simile all'esempio seguente. ``` {"SigninToken":"*** the SigninToken string ***"} ``` 1. **Nota** AWS supporta le richieste POST qui. Infine, crea l’URL che gli utenti possono usare per accedere alla Console di gestione AWS. L'URL corrisponde all'URL dell'endpoint di federazione usato in [Step 5](#STSConsoleLink_manual_step5), con l'aggiunta dei parametri seguenti: ``` ?Action = login &Issuer = *** the form-urlencoded URL for your internal sign-in page *** &Destination = *** the form-urlencoded URL to the desired AWS console page *** &SigninToken = *** the value of SigninToken received in the previous step *** ``` **Nota** Le seguenti istruzioni in questa fase funzionano solo con utilizzando l'API GET. L'esempio seguente mostra l'aspetto dell'URL finale. L'URL è valido per 15 minuti dal momento della creazione. Le credenziali di sicurezza temporanee e la sessione della console incorporate nell'URL sono valide per la durata specificata nel parametro HTTP `SessionDuration` al momento della richiesta iniziale. ``` https://signin.aws.amazon.com/federation ?Action=login &Issuer=https%3A%2F%2Fexample.com &Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F &SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1 WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u 3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv 9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm 0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC RNhujg ``` ## Codice di esempio con Python Gli esempi seguenti mostrano come usare Python a livello di programmazione per creare un URL che concede agli utenti l’accesso diretto alla Console di gestione AWS. Gli esempi sono due: + Federa tramite richieste GET a AWS + Federate tramite richieste POST a AWS Entrambi gli esempi utilizzano l'[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API [AWS SDK per Python (Boto3)](https://aws.amazon.com/tools/)and per ottenere credenziali di sicurezza temporanee. Non includere `SessionDuration` se le credenziali `AssumeRoleSession` provengono dalla concatenazione dei ruoli. Se si include `SessionDuration`, l’operazione avrà esito negativo. ### Utilizzo delle richieste GET ``` import urllib, json, sys import requests # 'pip install requests' import boto3 # AWS SDK for Python (Boto3) 'pip install boto3' # Step 1: Authenticate user in your own identity system. # Step 2: Using the access keys for an IAM user in your Account AWS, # call "AssumeRole" to get temporary access keys for the role or federated principal # Note: Calls to AWS STS AssumeRole must be signed using the access key ID # and secret access key of an IAM user or using existing temporary credentials. # The credentials can be in Amazon EC2 instance metadata, in environment variables, # or in a configuration file, and will be discovered automatically by the # client('sts') function. For more information, see the Python SDK docs: # http://boto3.readthedocs.io/en/latest/reference/services/sts.html # http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role sts_connection = boto3.client('sts') assumed_role_object = sts_connection.assume_role( RoleArn="arn:aws:iam::account-id:role/ROLE-NAME", RoleSessionName="AssumeRoleSession", ) # Step 3: Format resulting temporary credentials into JSON url_credentials = {} url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId') url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey') url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken') json_string_with_temp_credentials = json.dumps(url_credentials) # Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with # the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials # as parameters. request_parameters = "?Action=getSigninToken" request_parameters += "&SessionDuration=43200" if sys.version_info[0] < 3: def quote_plus_function(s): return urllib.quote_plus(s) else: def quote_plus_function(s): return urllib.parse.quote_plus(s) request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials) request_url = "https://signin.aws.amazon.com/federation" + request_parameters r = requests.get(request_url) # Returns a JSON document with a single element named SigninToken. signin_token = json.loads(r.text) # Step 5: Create URL where users can use the sign-in token to sign in to # the console. This URL must be used within 15 minutes after the # sign-in token was issued. request_parameters = "?Action=login" request_parameters += "&Issuer=Example.org" request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/") request_parameters += "&SigninToken=" + signin_token["SigninToken"] request_url = "https://signin.aws.amazon.com/federation" + request_parameters # Send final URL to stdout print (request_url) ``` ### Utilizzo delle richieste POST ``` import urllib, json, sys import requests # 'pip install requests' import boto3 # AWS SDK for Python (Boto3) 'pip install boto3' import os from selenium import webdriver # 'pip install selenium', 'brew install chromedriver' # Step 1: Authenticate user in your own identity system. # Step 2: Using the access keys for an IAM user in your A Account AWS, # call "AssumeRole" to get temporary access keys for the role or federated principal # Note: Calls to AWS STS AssumeRole must be signed using the access key ID # and secret access key of an IAM user or using existing temporary credentials. # The credentials can be in Amazon EC2 instance metadata, in environment variables, # or in a configuration file, and will be discovered automatically by the # client('sts') function. For more information, see the Python SDK docs: # http://boto3.readthedocs.io/en/latest/reference/services/sts.html # http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role if sys.version_info[0] < 3: def quote_plus_function(s): return urllib.quote_plus(s) else: def quote_plus_function(s): return urllib.parse.quote_plus(s) sts_connection = boto3.client('sts') assumed_role_object = sts_connection.assume_role( RoleArn="arn:aws:iam::account-id:role/ROLE-NAME", RoleSessionName="AssumeRoleDemoSession", ) # Step 3: Format resulting temporary credentials into JSON url_credentials = {} url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId') url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey') url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken') json_string_with_temp_credentials = json.dumps(url_credentials) # Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with # the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials # as parameters. request_parameters = {} request_parameters['Action'] = 'getSigninToken' request_parameters['SessionDuration'] = '43200' request_parameters['Session'] = json_string_with_temp_credentials request_url = "https://signin.aws.amazon.com/federation" r = requests.post( request_url, data=request_parameters) # Returns a JSON document with a single element named SigninToken. signin_token = json.loads(r.text) # Step 5: Create a POST request where users can use the sign-in token to sign in to # the console. The POST request must be made within 15 minutes after the # sign-in token was issued. request_parameters = {} request_parameters['Action'] = 'login' request_parameters['Issuer']='Example.org' request_parameters['Destination'] = 'https://console.aws.amazon.com/' request_parameters['SigninToken'] =signin_token['SigninToken'] jsrequest = ''' var form = document.createElement('form'); form.method = 'POST'; form.action = '{request_url}'; request_parameters = {request_parameters} for (var param in request_parameters) {{ if (request_parameters.hasOwnProperty(param)) {{ const hiddenField = document.createElement('input'); hiddenField.type = 'hidden'; hiddenField.name = param; hiddenField.value = request_parameters[param]; form.appendChild(hiddenField); }} }} document.body.appendChild(form); form.submit(); '''.format(request_url=request_url, request_parameters=request_parameters) driver = webdriver.Chrome() driver.execute_script(jsrequest) input("Press Enter to close the browser window...") ``` ## Esempio di codice con Java L’esempio seguente mostra come usare Java a livello di programmazione per creare un URL che concede agli utenti l’accesso diretto alla Console di gestione AWS. Nel frammento di codice seguente viene utilizzato [AWS SDK for Java](https://aws.amazon.com/documentation/sdkforjava/). ``` import java.net.URLEncoder; import java.net.URL; import java.net.URLConnection; import java.io.BufferedReader; import java.io.InputStreamReader; // Available at http://www.json.org/java/index.html import org.json.JSONObject; import com.amazonaws.auth.AWSCredentials; import com.amazonaws.auth.BasicAWSCredentials; import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient; import com.amazonaws.services.securitytoken.model.Credentials; import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest; import com.amazonaws.services.securitytoken.model.GetFederationTokenResult; /* Calls to AWS STS API operations must be signed using the access key ID and secret access key of an IAM user or using existing temporary credentials. The credentials should not be embedded in code. For this example, the code looks for the credentials in a standard configuration file. */ AWSCredentials credentials = new PropertiesCredentials( AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties")); AWSSecurityTokenServiceClient stsClient = new AWSSecurityTokenServiceClient(credentials); GetFederationTokenRequest getFederationTokenRequest = new GetFederationTokenRequest(); getFederationTokenRequest.setDurationSeconds(1800); getFederationTokenRequest.setName("UserName"); // A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console. String policy = "{\"Version\":\"2012-10-17\", \"Statement\":[{\"Action\":\"sns:*\"," + "\"Effect\":\"Allow\",\"Resource\":\"*\"}]}"; getFederationTokenRequest.setPolicy(policy); GetFederationTokenResult federationTokenResult = stsClient.getFederationToken(getFederationTokenRequest); Credentials federatedCredentials = federationTokenResult.getCredentials(); // The issuer parameter specifies your internal sign-in // page, for example https://mysignin.internal.mycompany.com/. // The console parameter specifies the URL to the destination console of the // AWS Management Console. This example goes to Amazon SNS. // The signin parameter is the URL to send the request to. String issuerURL = "https://mysignin.internal.mycompany.com/"; String consoleURL = "https://console.aws.amazon.com/sns"; String signInURL = "https://signin.aws.amazon.com/federation"; // Create the sign-in token using temporary credentials, // including the access key ID, secret access key, and session token. String sessionJson = String.format( "{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}", "sessionId", federatedCredentials.getAccessKeyId(), "sessionKey", federatedCredentials.getSecretAccessKey(), "sessionToken", federatedCredentials.getSessionToken()); // Construct the sign-in request with the request sign-in token action, a // 12-hour console session duration, and the JSON document with temporary // credentials as parameters. String getSigninTokenURL = signInURL + "?Action=getSigninToken" + "&DurationSeconds=43200" + "&SessionType=json&Session=" + URLEncoder.encode(sessionJson,"UTF-8"); URL url = new URL(getSigninTokenURL); // Send the request to the AWS federation endpoint to get the sign-in token URLConnection conn = url.openConnection (); BufferedReader bufferReader = new BufferedReader(new InputStreamReader(conn.getInputStream())); String returnContent = bufferReader.readLine(); String signinToken = new JSONObject(returnContent).getString("SigninToken"); String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8"); // The issuer parameter is optional, but recommended. Use it to direct users // to your sign-in page when their session expires. String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8"); // Finally, present the completed URL for the AWS console session to the user String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8"); String loginURL = signInURL + "?Action=login" + signinTokenParameter + issuerParameter + destinationParameter; ``` ## Esempio ci creazione dell'URL (Ruby) L’esempio seguente mostra come usare Ruby a livello di programmazione per creare un URL che concede agli utenti l’accesso diretto alla Console di gestione AWS. In questo frammento di codice viene utilizzato [AWS SDK for Ruby](https://aws.amazon.com/documentation/sdkforruby/). ``` require 'rubygems' require 'json' require 'open-uri' require 'cgi' require 'aws-sdk' # Create a new STS instance # # Note: Calls to AWS STS API operations must be signed using an access key ID # and secret access key. The credentials can be in EC2 instance metadata # or in environment variables and will be automatically discovered by # the default credentials provider in the AWS Ruby SDK. sts = Aws::STS::Client.new() # The following call creates a temporary session that returns # temporary security credentials and a session token. # The policy grants permissions to work # in the AWS SNS console. session = sts.get_federation_token({ duration_seconds: 1800, name: "UserName", policy: "{\"Version\":\"2012-10-17\", \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}", }) # The issuer value is the URL where users are directed (such as # to your internal sign-in page) when their session expires. # # The console value specifies the URL to the destination console. # This example goes to the Amazon SNS console. # # The sign-in value is the URL of the AWS STS federation endpoint. issuer_url = "https://mysignin.internal.mycompany.com/" console_url = "https://console.aws.amazon.com/sns" signin_url = "https://signin.aws.amazon.com/federation" # Create a block of JSON that contains the temporary credentials # (including the access key ID, secret access key, and session token). session_json = { :sessionId => session.credentials[:access_key_id], :sessionKey => session.credentials[:secret_access_key], :sessionToken => session.credentials[:session_token] }.to_json # Call the federation endpoint, passing the parameters # created earlier and the session information as a JSON block. # The request returns a sign-in token that's valid for 15 minutes. # Signing in to the console with the token creates a session # that is valid for 12 hours. get_signin_token_url = signin_url + "?Action=getSigninToken" + "&SessionType=json&Session=" + CGI.escape(session_json) returned_content = URI.parse(get_signin_token_url).read # Extract the sign-in token from the information returned # by the federation endpoint. signin_token = JSON.parse(returned_content)['SigninToken'] signin_token_param = "&SigninToken=" + CGI.escape(signin_token) # Create the URL to give to the user, which includes the # sign-in token and the URL of the console to open. # The "issuer" parameter is optional but recommended. issuer_param = "&Issuer=" + CGI.escape(issuer_url) destination_param = "&Destination=" + CGI.escape(console_url) login_url = signin_url + "?Action=login" + signin_token_param + issuer_param + destination_param ```