Accesso alle risorse multi-account in IAM

Per alcuni servizi AWS, è possibile concedere l'accesso multi-account alle risorse utilizzando IAM. A tale scopo, è possibile collegare una policy direttamente alla risorsa da condividere oppure utilizzare un ruolo come proxy.

Per condividere direttamente la risorsa, la risorsa da condividere deve supportare le policy basate su risorse. A differenza di una policy basata su identità per un ruolo, una policy basata su risorse specifica chi (quale principale) può accedere a tale risorsa.

Utilizza un ruolo come proxy quando desideri accedere a risorse di un altro account che non supportano le policy basate su risorse.

Per ulteriori dettagli sulle differenze tra questi tipi di policy, consulta la sezione Policy basate sulle identità e policy basate su risorse.

Nota

I ruoli IAM e le policy basate sulle risorse delegano l'accesso tra account solo all'interno di una singola partizione. Ad esempio, poniamo che tu abbia un account nella Regione Stati Uniti occidentali (California settentrionale) nella partizione aws standard. Hai anche un account in Cina nella partizione aws-cn. Non puoi utilizzare una policy basata su risorse nel tuo account in Cina per consentire l'accesso agli utenti del tuo account AWS standard.

Accesso multi-account tramite ruoli

Non tutti i servizi AWS supportano le policy basate su risorse. Per questi servizi, puoi utilizzare i ruoli IAM multi-account per centralizzare la gestione delle autorizzazioni quando fornisci l'accesso multi-account a più servizi. Un ruolo IAM multi-account è un ruolo IAM che include una policy di attendibilità che consente ai principali IAM di un altro account AWS di assumere il ruolo. In altre parole, puoi creare un ruolo in un account AWS che delega autorizzazioni specifiche a un altro account AWS.

Per informazioni sul collegamento di una policy a un'identità IAM, consulta Gestione di policy IAM.

Nota

Quando un principale passa a un ruolo per utilizzare temporaneamente le rispettive autorizzazioni, rinuncia alle autorizzazioni originali e assume quelle assegnate al ruolo che ha assunto.

Diamo un'occhiata al processo complessivo prendendo in esame un software di un partner APN che deve accedere a un account cliente.

1. Il cliente crea un ruolo IAM nel proprio account con una policy IAM che consente l'accesso alle risorse Amazon S3 richieste dal partner APN. In questo esempio, il nome del ruolo è APNPartner.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:*",
               "Resource": [
                   "arn:aws:s3:::bucket-name"
               ]
           }
       ]
   }

2. Quindi, il cliente specifica che il ruolo può essere assunto dall'account AWS del partner fornendo l'ID Account AWS del partner APN nella policy di attendibilità per il ruolo APNPartner.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "arn:aws:iam::APN-account-ID:role/APN-user-name"
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }

3. Il cliente fornisce il nome della risorsa Amazon (ARN) del ruolo al partner APN. L'ARN è il nome completo del ruolo.

   arn:aws:iam::APN-ACCOUNT-ID:role/APNPartner

   Nota

   Ti consigliamo di utilizzare un ID esterno in situazioni multi-tenant. Per informazioni dettagliate, consulta Come utilizzare un ID esterno quando si concede a una terza parte l'accesso alle proprie risorse AWS.

4. Quando il software del partner APN deve accedere all'account del cliente, il software chiama l'API AssumeRole in AWS Security Token Service insieme all'ARN del ruolo nell'account del cliente. STS restituisce una credenziale AWS temporanea che consente al software di svolgere il proprio lavoro.

Per un altro esempio di concessione dell'accesso multi-account utilizzando i ruoli, consulta la sezione Fornire l'accesso a un utente IAM in un altro Account AWS di proprietà dell'utente. Puoi anche seguire il Tutorial IAM: Delega dell'accesso tra account AWS tramite i ruoli IAM.

Accesso multi-account utilizzando policy basate su risorse

Quando un account accede a una risorsa tramite un altro account utilizzando una policy basata su risorse, il principale continua a utilizzare l'account attendibile e non deve rinunciare alle proprie autorizzazioni per ricevere quelle del ruolo. In altre parole, il principale ha accesso alle risorse dell'account attendibile e contemporaneamente alla risorsa nell'account che concede fiducia. Questa funzione è utile per attività come la copia di informazioni da o verso la risorsa condivisa nell'altro account.

I principali che è possibile specificare in una policy basata sulle risorse includono account, utenti IAM, utenti federati, ruoli IAM, sessioni con ruolo assunto o servizi AWS. Per ulteriori informazioni, consulta la sezione Specifica di un principale.

Per capire se i principali negli account esterni alla zona di attendibilità (organizzazione o account attendibile) dispongono dell'accesso per assumere i ruoli, consulta la sezione Identificazione di risorse condivise con un'entità esterna.

Nell'elenco seguente sono inclusi alcuni dei servizi AWS che supportano le policy basate sulle risorse. Per un elenco completo del numero crescente di servizi AWS che supportano il collegamento delle policy delle autorizzazioni alle risorse anziché alle entità principali, consulta AWS servizi che funzionano con IAM e cerca i servizi con per cui è indicato Yes (Sì) nella colonna Resource Based (Basata su risorse).

• Bucket Amazon S3: la policy è collegata al bucket, ma controlla l'accesso sia al bucket sia agli oggetti in esso contenuti. Per ulteriori informazioni, consulta Controllo accessi nella Guida per l’utente di Amazon Simple Storage Service. In alcuni casi, può essere opportuno utilizzare ruoli per l'accesso per più account ad Amazon S3. Per ulteriori informazioni, consulta le spiegazioni passo per passo di esempio nella Guida per l’utente di Amazon Simple Storage Service.

• Argomenti Amazon Simple Notification Service (Amazon SNS): per ulteriori informazioni, consulta la sezione Casi di esempio per il controllo degli accessi Amazon SNS nella Guida per gli sviluppatori di Amazon Simple Notification Service.

• Code di Amazon Simple Queue Service (Amazon SQS): per ulteriori informazioni, consulta Appendice: La sintassi della policy di accesso nellaGuida per gli sviluppatori di Amazon Simple Queue Service.

Delega delle autorizzazioni AWS in una policy basate su risorse

Se una risorsa concede le autorizzazioni ai principali nell'account, puoi delegare tali autorizzazioni a identità IAM specifiche. Le identità sono utenti, gruppi di utenti o ruoli nell'account. Per delegare le autorizzazioni, collegare una policy all'identità. È possibile concedere fino al numero massimo di autorizzazioni consentite dall'account proprietario della risorsa.

Importante

Nell'accesso multi-account, il principale deve disporre della condizione Allow nella policy di identità e nella policy basata su risorse.

Si supponga che una policy basata sulle risorse consenta a tutti i principali nell'account l'accesso amministrativo completo a una risorsa. È quindi possibile delegare l'accesso completo, l'accesso di sola lettura o qualsiasi altro accesso parziale ai principali nel proprio account AWS. In alternativa, se la policy basata sulle risorse consente solo le autorizzazioni per la presentazione di elenchi, è possibile delegare solo l'accesso all'elenco. Se si tenta di delegare più autorizzazioni rispetto a quelle possedute dall'account, i principali avranno comunque solo accesso all'elenco.

Per ulteriori informazioni su come vengono prese queste decisioni, consulta la sezione Determinare se una richiesta è consentita o rifiutata all'interno di un account.

Nota

I ruoli IAM e le policy basate sulle risorse delegano l'accesso tra account solo all'interno di una singola partizione. Ad esempio, non è possibile aggiungere l'accesso tra account tra un account nella partizione aws standard e un account nella partizione aws-cn.

Ad esempio, si supponga di gestire AccountA e AccountB. Nell'AccountA, disponi di un bucket Amazon S3 denominato BucketA.

1. Colleghi una policy basata su risorse ad BucketA che consente a tutti i principali nell'AccountB l'accesso completo agli oggetti nel bucket. Possono creare, leggere o eliminare qualsiasi oggetto in tale bucket.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "PrincipalAccess",
               "Effect": "Allow",
               "Principal": {"AWS": "arn:aws:iam::AccountB:root"},
               "Action": "s3:*",
               "Resource": "arn:aws:s3:::BucketA/*"
               }
           ]
   }

   AccountA fornisce all'AccountB l'accesso completo al BucketA denominando AccountB come un principale nella policy basata su risorse. Di conseguenza, l'AccountB è autorizzato a eseguire qualsiasi operazione nel BucketA e l'amministratore dell'AccountB può delegare l'accesso ai propri utenti nell'AccountB.

   L'utente root dell'AccountB dispone di tutte le autorizzazioni concesse all'account. Pertanto, l'utente root dispone di accesso completo al BucketA.

2. Nell'AccountB, collega una policy all'utente IAM denominato User2. Tale policy consente all'utente l'accesso in sola lettura agli oggetti nel BucketA. Ciò significa che User2 può visualizzare gli oggetti, ma non crearli, modificarli o eliminarli.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect" : "Allow", 
               "Action" : [ 
                   "s3:Get*", 
                   "s3:List*" ], 
                   "Resource" : "arn:aws:s3:::BucketA/*" 
           } 
       ]
   }

   Il livello massimo di accesso che AccountB è in grado di delegare è il livello di accesso concesso all'account. In questo caso, la policy basata su risorse ha concesso l'accesso completo all'AccountB, ma User2 dispone solo dell'accesso di sola lettura.

   L'amministratore dell'AccountB non concede l'accesso a User1. Per impostazione predefinita, gli utenti non dispongono di autorizzazioni ad eccezione di quelle concesse in modo esplicito, pertanto User1 non ha accesso al BucketA.

IAM valuta le autorizzazioni di un principale nel momento in cui il principale effettua una richiesta. Se utilizzi caratteri jolly (*) per consentire agli utenti l'accesso completo alle risorse, i principali possono accedere a qualsiasi risorsa alla quale l'account AWS ha accesso. Ciò vale anche per le risorse che vengono aggiunte o a cui si ha accesso dopo aver creato le policy dell'utente.

Nell'esempio precedente, se l'AccountB avesse collegato a User2 una policy che concedeva l'accesso completo a tutte le risorse in tutti gli account, User2 avrebbe automaticamente avuto accesso a qualsiasi risorsa alla quale ha accesso l'AccountB. Ciò include l'accesso al BucketA e l'accesso a qualsiasi altra risorsa concesso dalle policy basate su risorse nell'AccountA.

Per ulteriori informazioni sugli usi complessi dei ruoli, come la concessione dell'accesso ad applicazioni e servizi, consulta la sezione Scenari comuni per ruoli: utenti, applicazioni e servizi.

Importante

Concedere l'accesso solo a entità attendibili e fornire il livello minimo di accesso necessario. Ogni volta che l'entità attendibile è un altro account AWS, a qualsiasi principale IAM può essere concesso l'accesso alla tua risorsa. L'account AWS attendibile può delegare l'accesso solo nella misura in cui gli è stato concesso accesso; non può delegare un livello di accesso superiore a quanto non sia stato concesso all'account stesso.

Per ulteriori informazioni sulle autorizzazioni, le policy e il linguaggio di policy di autorizzazioni che è possibile utilizzare per scrivere policy, consultare Gestione degli accessi per le risorse AWS.