Fornire l'accesso a un utente IAM in un altro Account AWS di tua proprietà - AWS Identity and Access Management
Esempio di uno scenario in cui si utilizzano account di sviluppo e produzione separatiUlteriori informazioni

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

Fornire l'accesso a un utente IAM in un altro Account AWS di tua proprietà

Puoi concedere ai tuoi utenti IAM il permesso di passare a ruoli interni a te Account AWS o a ruoli definiti in altri ruoli Account AWS di tua proprietà.

Nota

Se desideri concedere l'accesso a un account che non possiedi né controlli, consulta Fornire l'accesso a Account AWS siti di proprietà di terzi più avanti in questo argomento.

Immaginiamo di avere delle istanze Amazon EC2 critiche per la tua organizzazione. Invece di concedere direttamente agli utenti l'autorizzazione a terminare le istanze, è possibile creare un ruolo con tali privilegi. Quindi consentire agli amministratori di passare al ruolo quando è necessario terminare un'istanza. In questo modo si aggiungono i seguenti livelli di protezione alle istanze:

  • È necessario concedere esplicitamente agli utenti il permesso di assumere quel ruolo.

  • I tuoi utenti devono passare attivamente al ruolo utilizzando AWS Management Console o assumere il ruolo utilizzando l' AWS API AWS CLI o.

  • È possibile aggiungere una Multi-Factor Authentication (MFA) al ruolo, in modo che solo gli utenti che accedono con un dispositivo MFA possano assumere quel ruolo. Per ulteriori informazioni su come configurare un ruolo in modo che gli utenti che assumono il ruolo debbano essere prima autenticati utilizzando l’autenticazione a più fattori (MFA), consulta Configurazione dell'accesso alle API protetto da MFA.

Consigliamo di utilizzare questo approccio per applicare il principio di privilegio minimo. Ciò significa limitare l'uso di autorizzazioni elevate unicamente a quelle volte in cui sono necessarie per operazioni specifiche. Per impedire le modifiche accidentali apportate agli ambienti sensibili, puoi utilizzare i ruoli, soprattutto se combinati con attività di audit per garantire che vengano utilizzati solo quando necessario.

Quando si crea un ruolo per questo scopo, è necessario specificare l'ID degli account da cui gli utenti devono accedere nell'elemento Principal della policy di affidabilità del ruolo. È quindi possibile concedere agli utenti specifici in tali altri account le autorizzazioni per passare al ruolo. 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?.

Un utente in un account può passare a un ruolo dello stesso o di un altro account. Mentre si usa il ruolo, l'utente è in grado di eseguire solo le azioni e accedere solo alle risorse consentite dal ruolo; le loro autorizzazioni utente originali sono sospese. Quando l'utente esce dal ruolo, le autorizzazioni utente originali vengono ripristinate.

Esempio di uno scenario in cui si utilizzano account di sviluppo e produzione separati

Immaginate che la vostra organizzazione disponga Account AWS di più elementi per isolare un ambiente di sviluppo da un ambiente di produzione. Gli utenti nell'account di sviluppo potrebbero occasionalmente aver bisogno di accedere alle risorse nell'account di produzione. Ad esempio, potrebbe essere necessario l'accesso a più account quando si sta richiedendo un aggiornamento dall'ambiente di sviluppo all'ambiente di produzione. Anche se è possibile creare identità separate (e password) per gli utenti che lavorano con entrambi gli account, la gestione delle credenziali per più account complica la gestione delle identità. Nell'illustrazione seguente, tutti gli utenti vengono gestiti nell'account di sviluppo, ma per alcuni sviluppatori è necessario un accesso limitato all'account di produzione. L'account di sviluppo dispone di due gruppi: collaudatori e sviluppatori, e ciascun gruppo ha la propria policy.

Utilizzare un ruolo per delegare le autorizzazioni a un utente in un account diverso

  1. Nell'account di produzione, un amministratore utilizza IAM per creare il ruolo UpdateApp in tale account. Nel ruolo, l'amministratore definisce una policy di affidabilità che specifica l'account di sviluppo come Principal; in tal modo gli utenti autorizzati dall'account di sviluppo possono utilizzare il ruolo UpdateApp. L'amministratore definisce inoltre una policy delle autorizzazioni per il ruolo che specifica le autorizzazioni in lettura e scrittura per il bucket Amazon S3 denominato productionapp.

    L'amministratore quindi condivide le informazioni appropriate con chiunque debba assumere quel ruolo. Tali informazioni sono il numero di account e il nome del ruolo (per gli utenti della AWS console) o l'Amazon Resource Name (ARN) (per AWS CLI l'accesso all' AWS API). L'ARN del ruolo può essere simile a arn:aws:iam::123456789012:role/UpdateApp, dove il ruolo è denominato UpdateApp ed è stato creato nel numero di account 123456789012.

    Nota

    L'amministratore può eventualmente configurare il ruolo in modo che gli utenti che assumono il ruolo debbano essere prima autenticati utilizzando l’autenticazione a più fattori (MFA). Per ulteriori informazioni, consulta Configurazione dell'accesso alle API protetto da MFA.

  2. Nell'account di sviluppo, un amministratore concede ai membri del gruppo di sviluppatori l'autorizzazione a cambiare il ruolo. Ciò viene fatto concedendo al gruppo Developers l'autorizzazione a chiamare l'AssumeRoleAPI AWS Security Token Service (AWS STS) per il UpdateApp ruolo. Qualsiasi utente IAM che appartiene al gruppo Sviluppatori nell'account di sviluppo può ora passare al ruolo UpdateApp nell'account di produzione. Gli altri utenti che non appartengono al gruppo di sviluppatori non hanno il permesso di passare al ruolo e pertanto non sono in grado di accedere al bucket S3 nell'account di produzione.

  3. L'utente richiede di cambiare il ruolo:

    • AWS console: l'utente sceglie il nome dell'account nella barra di navigazione e sceglie Switch Role. L'utente specifica l'ID account (o alias) e il nome del ruolo. In alternativa, l'utente può fare clic su un collegamento inviato nell'e-mail dall'amministratore. Il link indirizza l'utente alla pagina Switch Role (Cambia ruolo) con i dettagli già compilati.

    • AWS API/AWS CLI: Un utente del gruppo Developers dell'account di sviluppo chiama la AssumeRole funzione per ottenere le credenziali per il ruolo. UpdateApp L'utente specifica l'ARN del ruolo UpdateApp come parte della chiamata. Se un utente nel gruppo di collaudatori inoltra la stessa richiesta, la richiesta ha esito negativo perché i collaudatori non hanno l'autorizzazione a chiamare AssumeRole per il UpdateApp ruolo ARN.

  4. AWS STS restituisce credenziali temporanee:

    • AWS console: AWS STS verifica la richiesta con la politica di fiducia del ruolo per garantire che la richiesta provenga da un'entità attendibile (che è: l'account di sviluppo). Dopo la verifica, AWS STS restituisce le credenziali di sicurezza temporanee alla AWS console.

    • API/CLI: AWS STS verifica la richiesta rispetto alla politica di fiducia del ruolo per garantire che la richiesta provenga da un'entità attendibile (che è: l'account Development). Dopo la verifica, AWS STS restituisce le credenziali di sicurezza temporanee all'applicazione.

  5. Le credenziali temporanee consentono l'accesso alla AWS risorsa:

    • AWS console: la AWS console utilizza le credenziali temporanee per conto dell'utente per tutte le azioni successive della console, in questo caso, per leggere e scrivere nel productionapp bucket. La console non è in grado di accedere ad altre risorse nell'account di produzione. Quando l'utente esce dal ruolo, le autorizzazioni dell'utente tornano a quelle originali detenute prima di cambiare il ruolo.

    • API/CLI: l'applicazione utilizza le credenziali di sicurezza provvisorie per aggiornare il bucket productionapp. Con le credenziali di sicurezza provvisorie, l'applicazione può solo leggere e scrivere al bucket productionapp e non è in grado di accedere a qualsiasi altra risorsa nell'account di produzione. L'applicazione non deve uscire dal ruolo, bensì cessa di utilizzare le credenziali provvisorie e utilizza le credenziali originali nelle successive chiamate API.

Ulteriori informazioni

Per ulteriori informazioni, consulta gli argomenti seguenti: