Accesso per un IAM utente in un altro Account AWS di tua proprietà - 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à.

Accesso per un IAM utente in un altro Account AWS di tua proprietà

Puoi concedere ai tuoi IAM utenti 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 Accesso a Account AWS proprietà di terzi più avanti in questo argomento.

Immagina di avere EC2 istanze Amazon fondamentali 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 AWS CLI o AWS API.

  • Puoi aggiungere la protezione di autenticazione a più fattori (MFA) al ruolo in modo che solo gli utenti che accedono con un MFA dispositivo possano assumere il ruolo. Per informazioni su come configurare un ruolo in modo che gli utenti che assumono il ruolo debbano prima essere autenticati utilizzando l'autenticazione a più fattori (MFA), vedi. APIAccesso sicuro con 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 sapere se i responsabili di account che non rientrano nella tua zona di fiducia (organizzazione o account attendibile) possono assumere i tuoi ruoli, vedi 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 crea IAM il UpdateApp ruolo in quell'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 o AWS API accesso). Il ruolo ARN potrebbe essere simile arn:aws:iam::123456789012:role/UpdateApp a quello in cui il ruolo è denominato UpdateApp e il ruolo è stato creato con il numero di account 123456789012.

    Nota

    L'amministratore può facoltativamente configurare il ruolo in modo che gli utenti che assumono il ruolo debbano prima essere autenticati utilizzando l'autenticazione a più fattori (). MFA Per ulteriori informazioni, consulta APIAccesso sicuro con 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 di sviluppatori il permesso di chiamare il AWS Security Token Service (AWS STS) per il ruolo. AssumeRole API UpdateApp Qualsiasi IAM utente che appartiene al gruppo Developers nell'account di sviluppo può ora passare al UpdateApp ruolo 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 il ARN UpdateApp ruolo come parte della chiamata. Se un utente del gruppo Testers effettua la stessa richiesta, la richiesta ha esito negativo perché i tester non sono autorizzati a AssumeRole richiedere il ruolo. UpdateApp 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 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 temporanee 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, ma smette invece di utilizzare le credenziali temporanee e utilizza le credenziali originali nelle chiamate successive. API

Risorse aggiuntive

Per ulteriori informazioni, consulta gli argomenti seguenti: