Termini e concetti dei ruoli

UN'identità IAM che puoi creare nell'account che ha le autorizzazioni specifiche. Un ruolo IAM presenta alcune analogie con un utente IAM. Ruoli e utenti sono entrambi identità AWS con policy di autorizzazioni che determinano ciò che l'identità può o non può fare in AWS. Tuttavia, invece di essere associato in modo univoco a una persona, un ruolo è destinato a essere assunto da chiunque. Inoltre, un ruolo non ha credenziali a lungo termine standard associate (password o chiavi di accesso). Tuttavia, quando assumi un ruolo, vengono fornite le credenziali di sicurezza provvisorie per la sessione del ruolo.

I ruoli possono essere utilizzati da:

Un ruolo di servizio è un ruolo IAM che un servizio assume per eseguire operazioni per tuo conto. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall'interno di IAM. Per ulteriori informazioni, consulta la sezione Creazione di un ruolo per delegare le autorizzazioni a un Servizio AWS nella Guida per l'utente di IAM.

Un tipo speciale di ruolo di servizio che un'applicazione in esecuzione su un'istanza Amazon EC2 può assumere per eseguire operazioni nell'account. Questo ruolo è assegnato all'istanza EC2 quando viene avviata. Le applicazioni in esecuzione su quell'istanza possono recuperare credenziali di sicurezza provvisorie ed eseguire le operazioni consentite dal ruolo. Per ulteriori informazioni sull'utilizzo di un ruolo di servizio per un'istanza EC2, consulta la pagina Utilizzo di un ruolo IAM per concedere autorizzazioni alle applicazioni in esecuzione su istanze Amazon EC2.

Un ruolo collegato al servizio è un tipo di ruolo di servizio collegato a un. Servizio AWS Il servizio può assumere il ruolo per eseguire un'operazione per tuo conto. I ruoli collegati al servizio vengono visualizzati nel tuo account Account AWS e sono di proprietà del servizio. Un amministratore IAM può visualizzare le autorizzazioni per i ruoli collegati ai servizi, ma non modificarle.

Per informazioni su quali servizi supportano i ruoli collegati ai servizi, consulta la pagina AWS servizi che funzionano con IAM e cerca i servizi per cui è indicato Sì nella colonna Ruolo collegato ai servizi. Scegli Sì in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio. Per ulteriori informazioni, consulta Uso di ruoli collegati ai servizi.

Il concatenamento dei ruoli si verifica quando si utilizza un ruolo per assumere un secondo ruolo tramite l' AWS CLI API o. Ad esempio, RoleA dispone dell'autorizzazione per assumere il ruolo RoleB. È possibile consentire a User1 di assumere RoleA utilizzando le proprie credenziali utente a lungo termine nell' AssumeRole operazione API. Questa restituisce le credenziali a breve termine del ruolo RoleA. Con la concatenazione del ruolo, puoi utilizzare le credenziali a breve termine del ruolo RoleA per abilitare l'Utente1 ad assumere il ruolo RoleB.

Quando assumi un ruolo, puoi passare un tag di sessione e impostare il tag come transitivo. I tag di sessione transitivi vengono passati a tutte le sessioni successive in una concatenazione del ruolo. Per ulteriori informazioni sui tag di sessione, consulta Passare i tag di sessione AWS STS.

Il concatenamento dei ruoli limita la sessione di ruolo AWS dell'utente AWS CLI o dell'API a un massimo di un'ora. Quando si utilizza l'operazione AssumeRoleAPI per assumere un ruolo, è possibile specificare la durata della sessione di ruolo con il DurationSeconds parametro. Puoi specificare un valore di parametro fino a 43200 secondi (12 ore), che dipende dall'impostazione della durata massima della sessione per il tuo ruolo. Tuttavia, se assumi un ruolo utilizzando la concatenazione dei ruoli e fornisci un valore del parametro DurationSeconds maggiore di un'ora, l'operazione ha esito negativo.

AWS non considera l'utilizzo di ruoli per concedere autorizzazioni alle applicazioni eseguite su istanze EC2 come concatenamento di ruoli.

La concessione delle autorizzazioni a un altro utente per permettere l'accesso alle risorse di controllo. La delega comporta la configurazione di un trust tra due account. Il primo è l'account proprietario della risorsa (l'account che concede fiducia). Il secondo è l'account che contiene gli utenti che devono accedere alla risorsa (l'account attendibile). L'account a cui viene concessa fiducia e l'account che concede fiducia possono essere uno dei seguenti:

Per delegare l'autorizzazione per accedere a una risorsa, crea un ruolo IAM nell'account che concede fiducia che ha due policy collegate. Le policy di autorizzazioni concedono all'utente del ruolo le autorizzazioni necessarie per eseguire le attività previste sulla risorsa. La policy di attendibilità specifica quali membri degli account a cui viene concessa fiducia sono autorizzati ad assumere il ruolo.

Quando si crea una politica di affidabilità, non è possibile specificare un carattere jolly (*) come parte di un ARN come elemento principale. La policy di affidabilità è associata al ruolo nell'account che concede fiducia e rappresenta una metà delle autorizzazioni. L'altra metà è una policy delle autorizzazioni collegata all'utente nell'account a cui viene concessa fiducia che consente a quell'utente di passare al ruolo o di assumerlo. Un utente che assume un ruolo temporaneamente cede le proprie autorizzazioni e ottiene le autorizzazioni del ruolo. Quando l'utente esce o termina l'utilizzo del ruolo, le autorizzazioni originali dell'utente vengono ripristinate. Un parametro aggiuntivo chiamato external ID contribuisce a garantire sicuro l'uso dei ruoli tra gli account che non vengono controllati dalla stessa organizzazione.

La creazione di una relazione di fiducia tra un provider di identità esterno e. AWSGli utenti possono accedere a un provider OIDC, ad esempio Login with Amazon, Facebook, Google o qualsiasi IdP compatibile con OpenID Connect (OIDC). Gli utenti possono anche effettuare l'accesso a un sistema di identità enterprise compatibile con Security Assertion Markup Language (SAML) 2.0, ad esempio Microsoft Active Directory Federation Services. Quando utilizzi OIDC e SAML 2.0 per configurare una relazione di fiducia tra questi provider di identità esterni e AWS, all'utente viene assegnato un ruolo IAM. L'utente riceve anche credenziali temporanee che gli consentono di accedere alle risorse. AWS

Invece di creare un utente IAM, puoi utilizzare le identità esistenti provenienti dalla AWS Directory Service tua directory utente aziendale o da un provider OIDC. Questi sono noti come utenti federati. AWS assegna un ruolo a un utente federato quando l'accesso viene richiesto tramite un provider di identità. Per ulteriori informazioni sugli utenti federati, consulta Utenti federati e ruoli.

Documento di policy JSON in cui si definiscono i principali considerati attendibili per assumere il ruolo. Una policy di attendibilità del ruolo è una policy basata sulle risorse collegata a un ruolo in IAM. I principali che è possibile specificare nella policy di attendibilità includono utenti, ruoli, account e servizi.

Un documento delle autorizzazioni in formato JSON in cui definisci le operazioni e le risorse che il ruolo può utilizzare. Il documento è scritto in base alle regole del linguaggio della policy IAM.

Una funzione avanzata in cui usi le policy per limitare il numero massimo di autorizzazioni che una policy basata su identità può concedere a un ruolo. Non è possibile applicare un limite delle autorizzazioni a un ruolo collegato al servizio. Per ulteriori informazioni, consulta Limiti delle autorizzazioni per le entità IAM.

Un'entità in AWS grado di eseguire azioni e accedere alle risorse. Un principale può essere un Utente root dell'account AWS utente IAM o un ruolo. Puoi concedere le autorizzazioni ad accedere a una risorsa in uno dei seguenti due modi:

Se si fa riferimento a un Account AWS come principale, in genere si intende qualsiasi principale definito all'interno di quell'account.

Un ruolo che concede l'accesso alle risorse in un account a un principale affidabile in un diverso account. I ruoli sono lo strumento principale per concedere l'accesso multi-account. Tuttavia, alcuni dei servizi AWS ti consentono di collegare una policy direttamente a una risorsa (invece di utilizzare un ruolo come proxy). Queste sono chiamate politiche basate sulle risorse ed è possibile utilizzarle per concedere ai responsabili di un'altra persona l' Account AWS accesso alla risorsa. Alcune di queste risorse includono bucket Amazon Simple Storage Service (S3), vault S3 Glacier, argomenti Amazon Simple Notification Service (SNS) e code Amazon Simple Queue Service (SQS). Per informazioni su quali servizi supportano le policy basate su risorse, consulta AWS servizi che funzionano con IAM. Per ulteriori informazioni sulle policy basate sulle risorse, consulta Accesso alle risorse multi-account in IAM.