Accesso alle risorse multi-account in IAM - AWS Identity and Access Management
Accesso multi-account tramite ruoliAccesso multi-account utilizzando policy basate su risorseDelega delle AWS autorizzazioni in una politica basata sulle risorse

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 alle risorse multi-account in IAM

Per alcuni AWS servizi, puoi concedere l'accesso a più account alle tue 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 politica basata sulle risorse nel tuo account in Cina per consentire l'accesso agli utenti del tuo account standard. AWS

Accesso multi-account tramite ruoli

Non tutti i AWS servizi supportano politiche basate sulle 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 su più account è un ruolo IAM che include una policy di fiducia che consente ai responsabili IAM di un altro AWS account di assumere il ruolo. In poche parole, puoi creare un ruolo in un AWS account 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' AWS account del partner fornendo l' Account AWS ID del partner APN nella politica di fiducia relativa al 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, vedi Come utilizzare un ID esterno per concedere l'accesso alle proprie AWS risorse a terzi.

  4. Quando il software del partner APN deve accedere all'account del cliente, chiama l'AssumeRoleAPI AWS Security Token Service con l'ARN del ruolo nell'account del cliente. STS restituisce una AWS credenziale 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 tua proprietà. 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 principi che è possibile specificare in una policy basata sulle risorse includono account, utenti IAM, utenti federati, ruoli IAM, sessioni con ruolo presunto 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.

L'elenco seguente include alcuni dei AWS servizi che supportano le politiche basate sulle risorse. Per un elenco completo del numero crescente di AWS servizi che supportano l'associazione di politiche di autorizzazione alle risorse anziché ai principali, consulta AWS servizi che funzionano con IAM e cerca i servizi con Sì nella colonna Resource Based.

  • 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 AWS autorizzazioni in una politica basata sulle 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 puoi delegare l'accesso completo, l'accesso in sola lettura o qualsiasi altro accesso parziale ai principali del tuo 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.

Una policy basata su risorse creata per il bucket Amazon S3 fornisce le autorizzazioni dell'AccountB all'AccountA.

  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 usi i caratteri jolly (*) per consentire agli utenti l'accesso completo alle tue risorse, i mandanti possono accedere a tutte le risorse a cui ha accesso il tuo account. AWS 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à fidata è un altro AWS account, a qualsiasi responsabile IAM può essere concesso l'accesso alla tua risorsa. L' AWS account fidato può delegare l'accesso solo nella misura in cui gli è stato concesso l'accesso; non può delegare un accesso maggiore di quello 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 AWS alle risorse.