Autorizzazioni per AssumeRole, AssumeRoleWith SAML e AssumeRoleWithWebIdentity - AWS Identity and Access Management

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Autorizzazioni per 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 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.

PermissionsWhenPassingRoles_Diagramma

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'AssumeRoleWithWebIdentityAPI, 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.

Esempio 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.

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.

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/*" } ] }

Policy basata su 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.

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. AWSLogica di valutazione delle policy