

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

# Panoramica delle autorizzazioni di Lake Formation
<a name="lf-permissions-overview"></a>

Esistono due tipi principali di autorizzazioni in AWS Lake Formation:
+ Accesso ai metadati: autorizzazioni per le risorse del catalogo dati (autorizzazioni del *catalogo dati*). 

  Queste autorizzazioni consentono ai responsabili di creare, leggere, aggiornare ed eliminare database e tabelle di metadati nel Catalogo dati. 
+ Accesso ai dati di base: autorizzazioni su sedi in Amazon Simple Storage Service (Amazon S3) *(autorizzazioni di accesso ai dati* *e autorizzazioni di localizzazione dei dati*). 
  + Le autorizzazioni Data Lake consentono ai responsabili di leggere e scrivere dati nelle posizioni Amazon S3 *sottostanti*, dati a cui fanno riferimento le risorse del Data Catalog. 
  + Le autorizzazioni di localizzazione dei dati consentono ai responsabili di creare e modificare database e tabelle di metadati che puntano a posizioni Amazon S3 specifiche. 

Per entrambe le aree, Lake Formation utilizza una combinazione di autorizzazioni Lake Formation e autorizzazioni AWS Identity and Access Management (IAM). Il modello di autorizzazioni IAM è costituito da politiche IAM. Il modello di autorizzazioni di Lake Formation è implementato come GRANT/REVOKE comandi in stile DBMS, ad esempio. `Grant SELECT on tableName to userName`

Quando un principale effettua una richiesta di accesso alle risorse del Data Catalog o ai dati sottostanti, affinché la richiesta abbia esito positivo, deve superare i controlli di autorizzazione sia di IAM che di Lake Formation.

![\[La richiesta di un richiedente deve passare attraverso due «porte» per accedere alle risorse: le autorizzazioni Lake Formation e le autorizzazioni IAM.\]](http://docs.aws.amazon.com/it_it/lake-formation/latest/dg/images/permissions_doors.png)


Le autorizzazioni di Lake Formation controllano l'accesso alle risorse di Data Catalog, alle sedi Amazon S3 e ai dati sottostanti in tali sedi. Le autorizzazioni IAM controllano l'accesso a Lake Formation AWS Glue APIs e alle risorse. Quindi, anche se potresti avere l'autorizzazione Lake Formation per creare una tabella di metadati nel Data Catalog (`CREATE_TABLE`), l'operazione fallisce se non disponi dell'autorizzazione IAM sull'`glue:CreateTable`API. (Perché un'`glue:`autorizzazione? Perché Lake Formation utilizza il AWS Glue Data Catalog.)

**Nota**  
Le autorizzazioni di Lake Formation si applicano solo nella regione in cui sono state concesse.

AWS Lake Formation richiede che ogni principale (utente o ruolo) sia autorizzato a eseguire azioni sulle risorse gestite da Lake Formation. A un principale vengono concesse le autorizzazioni necessarie dall'amministratore del data lake o da un altro principale con le autorizzazioni per concedere le autorizzazioni di Lake Formation.

Quando concedi l'autorizzazione di Lake Formation a un preside, puoi facoltativamente concedere la possibilità di passare tale autorizzazione a un altro preside.

Puoi utilizzare l'API Lake Formation, il AWS Command Line Interface (AWS CLI) o le pagine **Data permissions e Data** **locations** della console Lake Formation per concedere e revocare le autorizzazioni Lake Formation.

# Metodi per il controllo granulare degli accessi
<a name="access-control-fine-grained"></a>

Con un data lake, l'obiettivo è avere un controllo granulare degli accessi ai dati. In Lake Formation, ciò significa un controllo granulare degli accessi alle risorse del Data Catalog e alle sedi Amazon S3. Puoi ottenere un controllo granulare degli accessi con uno dei seguenti metodi.


| Metodo | Autorizzazioni Lake Formation | Autorizzazioni IAM | Commenti | 
| --- | --- | --- | --- | 
| Metodo 1 | Aperta | A grana fine |  **Questo è il metodo predefinito per la compatibilità** con le versioni precedenti con. AWS Glue [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lake-formation/latest/dg/access-control-fine-grained.html) Sulla console Lake Formation, questo metodo ha il nome **Usa solo il controllo degli accessi IAM**.  | 
| Metodo 2 | A grana fine | A grana grossa |  **Questo è il metodo consigliato.** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lake-formation/latest/dg/access-control-fine-grained.html)  | 

**Importante**  
Ricorda quanto segue:  
Per impostazione predefinita, Lake Formation ha le impostazioni di **controllo degli accessi Use only IAM** abilitate per la compatibilità con il comportamento esistente del AWS Glue Data Catalog. Ti consigliamo di disabilitare queste impostazioni dopo la transizione all'utilizzo delle autorizzazioni di Lake Formation. Per ulteriori informazioni, consulta [Modifica delle impostazioni predefinite per il data lake](change-settings.md).
Gli amministratori di Data Lake e i creatori di database dispongono di autorizzazioni implicite di Lake Formation che devi comprendere. Per ulteriori informazioni, consulta [Autorizzazioni implicite di Lake Formation](implicit-permissions.md).

# Controllo dell'accesso ai metadati
<a name="access-control-metadata"></a>

Per il controllo degli accessi per le risorse del Data Catalog, la discussione seguente presuppone un controllo degli accessi a grana fine con le autorizzazioni di Lake Formation e un controllo degli accessi a grana grossa con le policy IAM.

Esistono due metodi distinti per concedere le autorizzazioni di Lake Formation sulle risorse del Data Catalog:
+ **Controllo dell'accesso alle risorse con nome**: con questo metodo, si concedono le autorizzazioni su database o tabelle specifici specificando i nomi dei database o delle tabelle. Le sovvenzioni hanno questa forma:

  Concedi *le autorizzazioni* ai *responsabili* sulle *risorse* [con opzione di concessione].

  Con l'opzione di concessione, puoi consentire al beneficiario di concedere le autorizzazioni ad altri mandanti.
+ **Controllo dell'accesso basato su tag**: con questo metodo, si assegnano uno o più tag LF ai database, alle tabelle e alle colonne del Data Catalog e si concedono le autorizzazioni su uno o più tag LF ai principali. Ogni tag LF è una coppia chiave-valore, ad esempio. `department=sales` Un principale con tag LF che corrispondono ai tag LF su una risorsa del catalogo dati può accedere a tale risorsa. Questo metodo è consigliato per i data lake con un gran numero di database e tabelle. È spiegato in dettaglio in[Controllo degli accessi basato su tag Lake Formation](tag-based-access-control.md).

Le autorizzazioni che un principale ha su una risorsa sono l'unione delle autorizzazioni concesse da entrambi i metodi.

La tabella seguente riassume le autorizzazioni di Lake Formation disponibili sulle risorse di Data Catalog. Le intestazioni delle colonne indicano la risorsa a cui è concessa l'autorizzazione.


| Catalogo | Database | Tabella | 
| --- | --- | --- | 
| CREATE\$1DATABASE | CREATE\$1TABLE | ALTER | 
|  | ALTER | DROP | 
|  | DROP | DESCRIBE | 
|  | DESCRIBE | SELECT\$1 | 
|  |  | INSERT\$1 | 
|  |  | DELETE\$1 | 

Ad esempio, l'`CREATE_TABLE`autorizzazione viene concessa a un database. Ciò significa che il principale è autorizzato a creare tabelle in quel database.

Le autorizzazioni con un asterisco (\$1) sono concesse alle risorse del Data Catalog, ma si applicano ai dati sottostanti. Ad esempio, l'`DROP`autorizzazione per una tabella di metadati consente di eliminare la tabella dal Data Catalog. Tuttavia, l'`DELETE`autorizzazione concessa sulla stessa tabella consente di eliminare i dati sottostanti della tabella in Amazon S3, utilizzando, ad esempio, un'istruzione SQL`DELETE`. Con queste autorizzazioni, puoi anche visualizzare la tabella sulla console Lake Formation e recuperare informazioni sulla tabella con l'AWS GlueAPI. Pertanto `SELECT``INSERT`, e `DELETE` sono sia le autorizzazioni di Data Catalog che le autorizzazioni di accesso ai dati.

Quando si concede la `SELECT` licenza su una tabella, è possibile aggiungere un filtro che includa o escluda una o più colonne. Ciò consente un controllo granulare degli accessi alle colonne della tabella di metadati, limitando le colonne che gli utenti dei servizi integrati possono vedere durante l'esecuzione delle query. Questa funzionalità non è disponibile utilizzando solo le policy IAM.

Esiste anche un'autorizzazione speciale denominata`Super`. L'`Super`autorizzazione consente a un principale di eseguire tutte le operazioni di Lake Formation supportate sul database o sulla tabella su cui è concessa. Questa autorizzazione può coesistere con le altre autorizzazioni di Lake Formation. Ad esempio, puoi concedere `Super` e `INSERT` su una tabella di metadati. `SELECT` Il principale può eseguire tutte le azioni supportate sulla tabella e, in caso di revoca, le autorizzazioni `SELECT` e `INSERT` rimangono `Super` invariate.

Per i dettagli su ciascuna autorizzazione, vedere. [Riferimento alle autorizzazioni di Lake Formation](lf-permissions-reference.md)

**Importante**  
Per poter visualizzare una tabella Data Catalog creata da un altro utente, è necessario disporre di almeno un'autorizzazione Lake Formation sulla tabella. Se ti viene concessa almeno un'autorizzazione sulla tabella, puoi anche vedere il database che contiene la tabella.

Puoi concedere o revocare le autorizzazioni di Data Catalog utilizzando la console Lake Formation, l'API o (). AWS Command Line Interface AWS CLI Di seguito è riportato un esempio di AWS CLI comando che concede all'utente il `datalake_user1` permesso di creare tabelle nel database. `retail`

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 
 --permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}'
```

Di seguito è riportato un esempio di policy IAM di controllo degli accessi a grana grossa che integra il controllo degli accessi a grana fine con le autorizzazioni di Lake Formation. Consente tutte le operazioni su qualsiasi database o tabella di metadati.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:*Database*",
                "glue:*Table*",
                "glue:*Partition*"
            ],
            "Resource": "*"
        }
    ]
}
```

------

L'esempio successivo è anch'esso a grana grossa ma leggermente più restrittivo. Consente operazioni di sola lettura su tutti i database e le tabelle di metadati nel Catalogo dati nell'account e nella regione designati.

------
#### [ JSON ]

****  

```
{  
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:GetTables",
                "glue:SearchTables",
                "glue:GetTable",
                "glue:GetDatabase", 
                "glue:GetDatabases"
            ],
            "Resource": "arn:aws:glue:us-east-1:111122223333:*"
        } 
    ]   
}
```

------

Confronta queste politiche con la seguente politica, che implementa il controllo granulare degli accessi basato su IAM. Concede le autorizzazioni solo su un sottoinsieme di tabelle nel database di metadati di gestione delle relazioni con i clienti (CRM) nell'account e nella regione designati.

------
#### [ JSON ]

****  

```
{  
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:GetTables",
                "glue:SearchTables",
                "glue:GetTable",
                "glue:GetDatabase", 
                "glue:GetDatabases"
            ],
            "Resource": [
                "arn:aws:glue:us-east-1:111122223333:catalog",
                "arn:aws:glue:us-east-1:111122223333:database/CRM",
                "arn:aws:glue:us-east-1:111122223333:table/CRM/P*"
            ]
        } 
    ]   
}
```

------

Per altri esempi di politiche di controllo degli accessi granulari, vedere. [Riferimento ai personaggi di Lake Formation e alle autorizzazioni IAM](permissions-reference.md)

# Controllo sottostante dell'accesso ai dati
<a name="access-control-underlying-data"></a>

Quando un AWS servizio integrato richiede l'accesso ai dati in una posizione Amazon S3 con accesso controllato da, Lake AWS Lake Formation Formation fornisce credenziali temporanee per accedere ai dati.

Per consentire a Lake Formation di controllare l'accesso ai dati sottostanti in una sede Amazon S3, devi *registrare* tale posizione con Lake Formation.

Dopo aver registrato una sede Amazon S3, puoi iniziare a concedere le seguenti autorizzazioni Lake Formation:
+ Autorizzazioni di accesso ai dati (`SELECT`,`INSERT`,) e `DELETE)` sulle tabelle di Data Catalog che puntano a quella posizione.
+ Autorizzazioni per l'ubicazione dei dati in quella posizione.

Le autorizzazioni di localizzazione dei dati di Lake Formation controllano la capacità di creare risorse Data Catalog che puntano a particolari posizioni Amazon S3. Le autorizzazioni di localizzazione dei dati forniscono un ulteriore livello di sicurezza alle posizioni all'interno del data lake. Quando concedi l'`ALTER`autorizzazione `CREATE_TABLE` o l'autorizzazione a un'entità principale, concedi anche le autorizzazioni per la localizzazione dei dati per limitare le posizioni per le quali l'ente principale può creare o modificare tabelle di metadati. 

Le sedi Amazon S3 sono bucket o prefissi all'interno di un bucket, ma non singoli oggetti Amazon S3.

Puoi concedere le autorizzazioni per la localizzazione dei dati a un principale utilizzando la console Lake Formation, l'API o il AWS CLI. La forma generale di una sovvenzione è la seguente: 

```
grant DATA_LOCATION_ACCESS to principal on S3 location [with grant option]
```

Se lo includi`with grant option`, il beneficiario può concedere le autorizzazioni ad altri committenti.

Ricorda che le autorizzazioni di Lake Formation funzionano sempre in combinazione con le autorizzazioni AWS Identity and Access Management (IAM) per un controllo granulare degli accessi. Per read/write le autorizzazioni sui dati Amazon S3 sottostanti, le autorizzazioni IAM vengono concesse come segue:

Quando registri una posizione, specifichi un ruolo IAM che concede autorizzazioni di lettura/scrittura su quella posizione. Lake Formation assume questo ruolo quando fornisce credenziali temporanee ai servizi integrati. AWS Un ruolo tipico potrebbe avere la seguente politica allegata, in cui la posizione registrata è il bucket. `awsexamplebucket`

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket"
            ]
        }
    ]
}
```

------

Lake Formation offre un ruolo collegato al servizio che puoi utilizzare durante la registrazione per creare automaticamente politiche come questa. Per ulteriori informazioni, consulta [Utilizzo di ruoli collegati ai servizi per Lake Formation](service-linked-roles.md).

Pertanto, la registrazione di una sede Amazon S3 concede le autorizzazioni `s3:` IAM richieste su quella posizione, dove le autorizzazioni sono specificate dal ruolo utilizzato per registrare la posizione.

**Importante**  
Evita di registrare un bucket Amazon S3 con Requester pay **abilitato**. Per i bucket registrati con Lake Formation, il ruolo utilizzato per registrare il bucket viene sempre visualizzato come richiedente. Se al bucket si accede da un altro AWS account, al proprietario del bucket viene addebitato l'accesso ai dati se il ruolo appartiene allo stesso account del proprietario del bucket.

Per read/write accedere ai dati sottostanti, oltre alle autorizzazioni di Lake Formation, i mandanti necessitano anche dell'autorizzazione `lakeformation:GetDataAccess` IAM. Con questa autorizzazione, Lake Formation concede la richiesta di credenziali temporanee per accedere ai dati.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "lakeformation:GetDataAccess",
            "Resource": "*"
        }
    ]
}
```

------

 Nella politica precedente, è necessario impostare il parametro Resource su '\$1' (all. La specificazione di altre risorse per questa autorizzazione non è supportata. Questa configurazione garantisce che Lake Formation possa gestire l'accesso ai dati nell'intero ambiente di data lake in modo efficiente. 

**Nota**  
Amazon Athena richiede che l'utente disponga dell'`lakeformation:GetDataAccess`autorizzazione. Altri servizi integrati richiedono che il ruolo di esecuzione sottostante disponga dell'`lakeformation:GetDataAccess`autorizzazione.

Questa autorizzazione è inclusa nelle politiche suggerite in[Riferimento ai personaggi di Lake Formation e alle autorizzazioni IAM](permissions-reference.md).

Riassumendo, per consentire ai dirigenti di Lake Formation di leggere e scrivere i dati sottostanti con accesso controllato dai permessi di Lake Formation:
+ Registra le sedi Amazon S3 che contengono i dati con Lake Formation.
+ I responsabili che creano tabelle Data Catalog che puntano alle posizioni dei dati sottostanti devono disporre delle autorizzazioni per la localizzazione dei dati.
+ I responsabili che leggono e scrivono i dati sottostanti devono disporre delle autorizzazioni di accesso ai dati di Lake Formation sulle tabelle del Data Catalog che puntano alle posizioni dei dati sottostanti.
+ I responsabili che leggono e scrivono i dati sottostanti devono disporre dell'autorizzazione `lakeformation:GetDataAccess` IAM quando la posizione dei dati sottostanti è registrata con Lake Formation.

**Nota**  
Il modello di autorizzazioni Lake Formation non impedisce l'accesso alle sedi Amazon S3 tramite l'API o la console di Amazon S3 se hai accesso ad esse tramite policy IAM o Amazon S3. Puoi collegare le policy IAM ai principali per bloccare questo accesso.

**Ulteriori informazioni sulle autorizzazioni per la localizzazione dei dati**  
Le autorizzazioni di localizzazione dei dati regolano il risultato delle operazioni di creazione e aggiornamento su database e tabelle Data Catalog. Le regole sono le seguenti:
+ Un principale deve disporre di autorizzazioni esplicite o implicite per la localizzazione dei dati su una posizione Amazon S3 per creare o aggiornare un database o una tabella che specifichi tale posizione.
+ L'autorizzazione esplicita `DATA_LOCATION_ACCESS` viene concessa utilizzando la console, l'API o. AWS CLI
+ Le autorizzazioni implicite vengono concesse quando un database ha una proprietà location che punta a una posizione registrata, il principale dispone dell'`CREATE_TABLE`autorizzazione sul database e il principale tenta di creare una tabella in quella posizione o in una posizione secondaria.
+ Se a un responsabile vengono concesse le autorizzazioni per la localizzazione dei dati su una posizione, il responsabile dispone delle autorizzazioni per la localizzazione dei dati su tutte le sedi secondarie.
+ Un responsabile non necessita delle autorizzazioni di localizzazione dei dati per eseguire read/write operazioni sui dati sottostanti. È sufficiente disporre delle `SELECT` o delle autorizzazioni di accesso ai `INSERT` dati. Le autorizzazioni per la localizzazione dei dati si applicano solo alla creazione di risorse del Catalogo Dati che puntano alla posizione.

Considerate lo scenario illustrato nel diagramma seguente.

![\[Gerarchia di cartelle e due database, il database A e B, con il database B che punta alla cartella Servizio clienti.\]](http://docs.aws.amazon.com/it_it/lake-formation/latest/dg/images/location-permissions-example.png)


In questo diagramma:
+ I bucket `Products` Amazon S3 `Customer Service` sono registrati presso Lake Formation. `Finance`
+ `Database A`non ha una proprietà di posizione e `Database B` dispone di una proprietà di posizione che punta al `Customer Service` bucket.
+ L'utente `datalake_user` ha `CREATE_TABLE` su entrambi i database.
+ All'utente sono `datalake_user` state concesse le autorizzazioni per la localizzazione dei dati solo nel `Products` bucket. 

Di seguito sono riportati i risultati ottenuti quando l'utente `datalake_user` tenta di creare una tabella di catalogo in un particolare database in una posizione particolare.


**Posizione in cui `datalake_user` tenta di creare una tabella**  

| Database e posizione | Ha successo o fallisce | Motivo | 
| --- | --- | --- | 
| Database A in Finance/Sales | Fallisce | Nessuna autorizzazione per la localizzazione dei dati | 
| Database A in Products | Ha successo | Dispone dell'autorizzazione alla localizzazione dei dati | 
| Database A in HR/Plans | Ha successo | La posizione non è registrata | 
| Database B in Customer Service/Incidents | Ha successo | Il database ha la proprietà di localizzazione in Customer Service | 

Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Aggiungere una posizione Amazon S3 al tuo data lake](register-data-lake.md)
+ [Riferimento alle autorizzazioni di Lake Formation](lf-permissions-reference.md)
+ [Riferimento ai personaggi di Lake Formation e alle autorizzazioni IAM](permissions-reference.md)