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à.
# Come concedere l'accesso multi-account
Autorizzazione dell'accesso alle risorse del catalogo dati tra account consente ai processi di estrazione, trasformazione e caricamento (ETL) di eseguire query e join di dati da account diversi.
**Topics**
+ [Metodi per concedere l'accesso multi-account in AWS Glue](#cross-account-how-works)
+ [Aggiunta o aggiornamento della policy della risorsa di catalogo dati](#cross-account-adding-resource-policy)
+ [Come effettuare una chiamata API multi-account](#cross-account-calling)
+ [Come effettuare una chiamata ETL multi-account](#cross-account-calling-etl)
+ [Registrazione su più account CloudTrail](#cross-account-ct-logs)
+ [Proprietà e fatturazione delle risorse multi-account](#cross-account-ownership-and-billing)
+ [Restrizioni di accesso multi-account](#cross-account-limitations)
## Metodi per concedere l'accesso multi-account in AWS Glue
Puoi concedere l'accesso ai tuoi dati ad AWS account esterni utilizzando AWS Glue metodi o utilizzando sovvenzioni AWS Lake Formation tra account. I AWS Glue metodi utilizzano policy AWS Identity and Access Management (IAM) per ottenere un controllo granulare degli accessi. Lake Formation utilizza un modello di autorizzazioni `GRANT/REVOKE` più semplice, simile ai comandi `GRANT/REVOKE` in un sistema di database relazionale.
In questa sezione viene descritto l'utilizzo dei metodi AWS Glue. Per ulteriori informazioni sull'utilizzo delle autorizzazioni multi-account Lake Formation, consulta [Concedere autorizzazioni Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/lake-formation-permissions.html) nella *Guida per gli sviluppatori di AWS Lake Formation *.
Sono disponibili due metodi AWS Glue, per concedere l'accesso multi-account a una risorsa:
+ Utilizzare una policy della risorsa del catalogo dati
+ Utilizzare un ruolo IAM
**Concedere l'accesso multi-account utilizzando una policy della risorsa**
Di seguito sono riportati i passaggi generali per concedere l'accesso multi-account utilizzando una policy della risorsa del catalogo dati:
1. Un amministratore (o un altro tipo di identità autorizzato) nell'Account A collega una policy della risorsa del catalogo dati nell'account A. Questa policy concede all'account B autorizzazioni multi-account specifiche per eseguire operazioni su una risorsa in un catalogo dell'account A.
1. Un amministratore nell'account B collega una policy IAM a un'identità IAM nell'account B che delega le autorizzazioni ricevute dall'Account A.
L'identità nell'account B ora ha accesso alla risorsa specificata nell'account A.
Per poter accedere alla risorsa, l'identità necessita dell'autorizzazione *sia* da parte del proprietario della risorsa (Account A), *sia* del relativo account padre (Account B).
**Concedere l'accesso multi-account utilizzando un ruolo IAM**
Di seguito sono riportati i passaggi generali per concedere l'accesso multi-account utilizzando un ruolo IAM:
1. Un amministratore (o un altro tipo di identità autorizzato) nell'account proprietario della risorsa (Account A) crea un ruolo IAM.
1. L'amministratore nell'Account A collega una policy al ruolo che concede autorizzazioni multi-account per accedere alla risorsa in questione.
1. L'amministratore dell'account A collega una policy di attendibilità al ruolo che identifica un'identità IAM in un account differente (Account B) come il principale che può assumere il ruolo.
Il responsabile della politica di fiducia può anche essere un responsabile del AWS servizio se si desidera concedere a un AWS servizio l'autorizzazione ad assumere il ruolo.
1. Un amministratore nell'account B ora delega le autorizzazioni a una o più identità IAM nell'account B in modo che possano assumere quel ruolo. In questo modo, consente alle identità nell'account B di accedere alla risorsa nell'account A.
Per ulteriori informazioni sull'uso di IAM per delegare le autorizzazioni, consultare [Gestione degli accessi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) nella *Guida per l'utente di IAM*. Per ulteriori informazioni su utenti, gruppi, ruoli e autorizzazioni, consultare [Identità (utenti, gruppi e ruoli)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) nella *Guida per l'utente di IAM*.
Per confrontare questi due approcci, consulta [In che modo i ruoli IAM differiscono dalle policy basate sulla risorsa](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) nella *Guida per l'utente IAM*. AWS Glue supporta entrambe le opzioni, con la limitazione che una policy della risorsa può concedere l'accesso solo alle risorse di catalogo dati.
Ad esempio, per concedere al ruolo `Dev` nell'account B l'accesso al database `db1` nell'account A, collegare al catalogo nell'account A le seguenti policy sulle risorse.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase"
],
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Dev"
]
},
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
Inoltre, prima che B possa effettivamente accedere a `db1` nell'account A, l'account B dovrebbe collegare al ruolo `Dev` la seguente policy IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
## Aggiunta o aggiornamento della policy della risorsa di catalogo dati
Puoi aggiungere o aggiornare la politica delle risorse di AWS Glue Data Catalog utilizzando la console, l'API o AWS Command Line Interface (AWS CLI).
**Importante**
Se hai già concesso autorizzazioni multi-account dal tuo account con AWS Lake Formation, l'aggiunta o l'aggiornamento della policy della risorsa del catalogo dati richiede un passaggio aggiuntivo. Per ulteriori informazioni, consulta [Gestire autorizzazioni multi-account tramite AWS Glue e Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/hybrid-cross-account.html) nella *Guida per gli sviluppatori di AWS Lake Formation *.
Per determinare se esistono concessioni multi-account di Lake Formation, utilizza l'operazione dell'API `glue:GetResourcePolicies` o la AWS CLI. Se `glue:GetResourcePolicies` restituisce policy diverse da una policy catalogo dati già esistente, allora esistono concessioni Lake Formation. Per ulteriori informazioni, consulta [Visualizzazione di tutte le sovvenzioni tra account utilizzando il funzionamento dell' GetResourcePolicies API nella Guida](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-getresourcepolicies.html) per gli *AWS Lake Formation sviluppatori*.
**Aggiunta o aggiornamento della policy della risorsa del catalogo dati (console)**
1. Apri la console AWS Glue all'indirizzo [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
Accedi come utente amministrativo AWS Identity and Access Management (IAM) con l'`glue:PutResourcePolicy`autorizzazione.
1. Nel pannello di navigazione scegli **Impostazioni**.
1. Nella pagina **Data catalog settings** (Impostazioni del catalogo dati), sotto**Permissions** (Autorizzazioni) incolla una policy della risorsa nell'area di testo. Quindi scegli **Save** (Salva).
Se nella console viene visualizzato un avviso che indica che le autorizzazioni della policy saranno in aggiunta alle autorizzazioni concesse tramite Lake Formation, scegli **Proceed** (Continua).
**Per aggiungere o aggiornare la policy della risorsa del catalogo dati (AWS CLI)**
+ Invia un comando `aws glue put-resource-policy`. Se esistono già concessioni per la Lake Formation, assicurati di includere l'opzione `--enable-hybrid` con il valore `'TRUE'`.
Per esempi di utilizzo di questo comando, consulta [Esempi di policy basate sulle risorse per Glue AWS](security_iam_resource-based-policy-examples.md).
## Come effettuare una chiamata API multi-account
Tutte le operazioni AWS Glue Data Catalog dispongono di un campo `CatalogId`. Se sono state concesse le autorizzazioni necessarie per l'accesso a più account, un chiamante è in grado di effettuare chiamate API del catalogo dati su tutti gli account. Il chiamante passa l'ID dell'account AWS di destinazione nel `CatalogId` in modo da accedere alla risorsa in tale account di destinazione.
Se non viene specificato alcun valore `CatalogId`, AWS Glue utilizza il proprio ID account del chiamante per impostazione predefinita e la chiamata non è multi-account.
## Come effettuare una chiamata ETL multi-account
Alcuni AWS Glue PySpark e Scala APIs hanno un campo ID del catalogo. Se sono state PySpark concesse tutte le autorizzazioni necessarie per consentire l'accesso tra account diversi, un job ETL può effettuare chiamate Scala alle operazioni API tra più account inserendo l'ID dell'account di destinazione nel campo ID del catalogo per accedere alle risorse del Data Catalog in un AWS account di destinazione.
Se non viene specificato alcun valore ID catalogo, AWS Glue utilizza il proprio ID account del chiamante per impostazione predefinita e la chiamata non è multi-account.
Per PySpark APIs tale assistenza`catalog_id`, consulta. [GlueContext classe](aws-glue-api-crawler-pyspark-extensions-glue-context.md) Per il supporto APIs di Scala`catalogId`, vedi[AWS GlueScala GlueContext APIs](glue-etl-scala-apis-glue-gluecontext.md).
L'esempio seguente mostra le autorizzazioni richieste dall'assegnatario per l'esecuzione di un processo ETL. In questo esempio, *grantee-account-id* è il `catalog-id` client che esegue il job ed *grantor-account-id* è il proprietario della risorsa. Questo esempio illustra come concedere le autorizzazioni per tutte le risorse del catalogo nell'account del concedente. Per limitare l'ambito delle risorse concesse, è possibile fornire informazioni specifiche ARNs per il catalogo, il database, la tabella e la connessione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetConnection",
"glue:GetDatabase",
"glue:GetTable",
"glue:GetPartition"
],
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Resource": [
"arn:aws:glue:us-east-1:111122223333:*"
]
}
]
}
```
------
**Nota**
Se una tabella nell'account del concedente punta a una posizione Amazon S3 che si trova anche nell'account del concedente, il ruolo IAM utilizzato per eseguire un processo ETL negli account dell'assegnatario deve avere le autorizzazioni per elencare e ottenere gli oggetti dall'account del concedente.
Poiché il client nell'Account A dispone già dell'autorizzazione per creare ed eseguire processi ETL, i passaggi di base per configurare un processo ETL per l'accesso multi-account sono i seguenti:
1. Consentire l'accesso ai dati multi-account (salta questo passaggio se l'accesso multi-account Amazon S3 è già configurato).
1. Aggiornare la policy nel bucket Amazon S3 nell'account B per consentire l'accesso multi-account dall'Account A.
1. Aggiornare la policy IAM nel bucket A per concedere l'accesso al bucket nell'account B.
1. Consentire l'accesso al catalogo dati multi-account
1. Creare o aggiornare la policy della risorsa associata al catalogo dati nell'account B per consentire l'accesso da parte di un account A.
1. Aggiornare la policy IAM nell'account A per consentire l'accesso al catalogo dati nell'account B.
## Registrazione su più account CloudTrail
Quando un job AWS Glue di estrazione, trasformazione e caricamento (ETL) accede ai dati sottostanti di una tabella Data Catalog condivisa tramite concessioni tra AWS Lake Formation account, si verifica un comportamento di registrazione aggiuntivo. AWS CloudTrail
Ai fini di questa discussione, l' AWS account che ha condiviso la tabella è l'account del proprietario e l'account con cui è stata condivisa la tabella è l'account del destinatario. Quando un processo ETL nell'account del destinatario accede ai dati nella tabella dell'account del proprietario, l' CloudTrail evento di accesso ai dati che viene aggiunto ai registri dell'account del destinatario viene copiato nei registri dell'account del proprietario. CloudTrail In questo modo gli account proprietari possono tenere traccia degli accessi ai dati da parte dei vari account destinatari. Per impostazione predefinita, gli CloudTrail eventi non includono un identificatore principale leggibile dall'uomo (ARN principale). Un amministratore nell'account destinatario può scegliere di includere l'ARN principale nei log.
*Per ulteriori informazioni, consulta Registrazione [tra account CloudTrail](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-logging.html) nella Guida per gli sviluppatori.AWS Lake Formation *
**Vedi anche**
[Registrazione e monitoraggio AWS Glue](logging-and-monitoring.md)
## Proprietà e fatturazione delle risorse multi-account
Quando un utente di un AWS account (Account A) crea una nuova risorsa, ad esempio un database in un altro account (Account B), quella risorsa è quindi di proprietà dell'Account B, l'account in cui è stata creata. Un amministratore nell'account B ottiene automaticamente tutte le autorizzazioni per accedere alla nuova risorsa, tra cui la lettura, la scrittura e la concessione di autorizzazioni di accesso a un terzo account. L'utente nell'account A può accedere alla risorsa che ha creato solo se dispone delle autorizzazioni appropriate concesse dall'account B.
I costi di storage e gli altri costi direttamente associati alla nuova risorsa vengono fatturati all'account B, il proprietario della risorsa. Il costo delle richieste dall'utente che ha creato la risorsa viene fatturato all'account del richiedente, l'account A.
Per ulteriori informazioni sulla AWS Glue fatturazione e sui prezzi, consulta [Come funzionano AWS i prezzi](https://d0.awsstatic.com/whitepapers/aws_pricing_overview.pdf).
## Restrizioni di accesso multi-account
L'accesso multi-account AWS Glue presenta le restrizioni seguenti:
+ L'accesso tra account AWS Glue non è permesso se hai creato database e tabelle utilizzando Amazon Athena o Amazon Redshift Spectrum prima del supporto di una Regione per AWS Glue e se l'account del proprietario della risorsa non ha migrato il catalogo dati di Amazon Athena verso AWS Glue. Puoi trovare l'attuale stato di migrazione utilizzando [GetCatalogImportStatus (get\$1catalog\$1import\$1status)](aws-glue-api-catalog-migration.md#aws-glue-api-catalog-migration-GetCatalogImportStatus). Per ulteriori dettagli su come migrare un catalogo Athena verso, [consulta l'aggiornamento AWS Glue](https://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html) alla versione contenuta AWS Glue Data Catalog step-by-step nella Amazon *Athena* User Guide.
+ L'accesso multi-account è supportato *solo* per le risorse del catalogo dati, tra cui database, tabelle, funzioni definite dall'utente e connessioni.
+ L'accesso multi-account al catalogo dati da Athena richiede di registrare il catalogo come risorsa Athena `DataCatalog`. Per istruzioni, consulta [Registrazione di un AWS Glue Data Catalog da un altro account](https://docs.aws.amazon.com/athena/latest/ug/data-sources-glue-cross-account.html) nella *Guida per l'utente di Amazon Athena*.