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à. # Le migliori pratiche, considerazioni e limitazioni di Lake Formation Usa questa sezione per trovare rapidamente le migliori pratiche, le considerazioni e le limitazioni all'interno. AWS Lake Formation Consulta le [quote di servizio](https://docs.aws.amazon.com/general/latest/gr/lake-formation.html#limits_lake-formation) per il numero massimo di risorse o operazioni di servizio per la tua. Account AWS **Topics** + [ # Buone pratiche e considerazioni sulla condivisione dei dati tra account ](cross-account-notes.md) + [ # Limitazioni dei ruoli legati ai servizi ](service-linked-role-limitations.md) + [ # Limitazioni di accesso ai dati tra regioni ](x-region-considerations.md) + [ # Visualizzazioni, considerazioni e limitazioni di Data Catalog ](views-notes.md) + [ # Limitazioni del filtraggio dei dati ](data-filtering-notes.md) + [ # Considerazioni e limitazioni della modalità di accesso ibrido ](notes-hybrid.md) + [ # Limitazioni per l'inserimento dei dati del data warehouse di Amazon Redshift nel AWS Glue Data Catalog ](notes-ns-catalog.md) + [ # Limitazioni dell'integrazione del catalogo S3 Tables ](notes-s3-catalog.md) + [ # I metadati di Hive archiviano: considerazioni e limitazioni sulla condivisione dei dati ](notes-hms.md) + [ # Limitazioni della condivisione dei dati di Amazon Redshift ](notes-rs-datashare.md) + [ # Limitazioni dell'integrazione di IAM Identity Center ](identity-center-lf-notes.md) + [ # Buone pratiche e considerazioni per il controllo degli accessi basato su tag Lake Formation ](lf-tag-considerations.md) + [ # Considerazioni, limitazioni e aree supportate sul controllo degli accessi basato sugli attributi ](abac-considerations.md) # Buone pratiche e considerazioni sulla condivisione dei dati tra account Le funzionalità cross-account di Lake Formation consentono agli utenti di condividere in modo sicuro i data lake distribuiti tra più AWS organizzazioni o direttamente con i responsabili IAM in un altro account Account AWS, fornendo un accesso granulare ai metadati del Data Catalog e ai dati sottostanti. Prendi in considerazione le seguenti best practice per l'utilizzo della condivisione di dati tra account di Lake Formation: + Non c'è limite al numero di concessioni di autorizzazioni di Lake Formation che puoi concedere ai mandanti per tuo conto. AWS Tuttavia, Lake Formation utilizza la capacità AWS Resource Access Manager (AWS RAM) per le sovvenzioni tra account che il tuo account può effettuare con il metodo delle risorse denominato. Per massimizzare la AWS RAM capacità, segui queste migliori pratiche per il metodo delle risorse denominate: + Utilizza la nuova modalità di concessione tra account (**versione 3** e successive nelle **impostazioni della versione Cross account**) per condividere una risorsa con un esterno. Account AWS Per ulteriori informazioni, consulta [Aggiornamento delle impostazioni della versione di condivisione dei dati tra account](optimize-ram.md). + Suddividi AWS gli account in organizzazioni e concedi le autorizzazioni alle organizzazioni o alle unità organizzative. Una concessione a un'organizzazione o a un'unità organizzativa conta come un'unica concessione. La concessione a organizzazioni o unità organizzative elimina inoltre la necessità di accettare un AWS Resource Access Manager (AWS RAM) invito alla condivisione di risorse per la sovvenzione. Per ulteriori informazioni, consulta [Accesso e visualizzazione di tabelle e database di Data Catalog condivisi](viewing-shared-resources.md). + Invece di concedere le autorizzazioni su molte singole tabelle di un database, utilizzate la speciale jolly **Tutte le tabelle** per concedere le autorizzazioni su tutte le tabelle del database. La concessione su **tutte le tabelle** viene considerata un'unica concessione. Per ulteriori informazioni, consulta [Concessione delle autorizzazioni per le risorse del Data Catalog](granting-catalog-permissions.md). **Nota** Per ulteriori informazioni sulla richiesta di un limite più elevato per il numero di condivisioni di risorse in AWS RAM, vedere le [quote AWS di servizio](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) nel. *Riferimenti generali di AWS* + È necessario creare un link di risorsa a un database condiviso affinché tale database appaia negli Amazon Athena editor di query di Amazon Redshift Spectrum. Analogamente, per poter eseguire query su tabelle condivise utilizzando Athena e Redshift Spectrum, è necessario creare collegamenti di risorse alle tabelle. I collegamenti alle risorse vengono quindi visualizzati nell'elenco delle tabelle degli editor di query. Invece di creare collegamenti alle risorse per molte singole tabelle per eseguire interrogazioni, è possibile utilizzare il carattere jolly **Tutte le tabelle** per concedere le autorizzazioni su tutte le tabelle di un database. Quindi, quando crei un link a una risorsa per quel database e lo selezioni nell'editor di query, avrai accesso a tutte le tabelle del database per la tua query. Per ulteriori informazioni, consulta [Creazione di collegamenti alle risorse](creating-resource-links.md). + Quando condividi risorse direttamente con i responsabili di un altro account, il responsabile IAM dell'account destinatario potrebbe non avere l'autorizzazione a creare collegamenti alle risorse per poter interrogare le tabelle condivise utilizzando Athena e Amazon Redshift Spectrum. Invece di creare un link a una risorsa per ogni tabella condivisa, l'amministratore del data lake può creare un database segnaposto e concedere `CREATE_TABLE` l'autorizzazione al gruppo. `ALLIAMPrincipal` Quindi, tutti i responsabili IAM presenti nell'account del destinatario possono creare collegamenti alle risorse nel database placeholder e iniziare a interrogare le tabelle condivise. Vedi il comando CLI di esempio per concedere le autorizzazioni a in. `ALLIAMPrincipals` [Concessione delle autorizzazioni al database tramite il metodo delle risorse denominate](granting-database-permissions.md) + Quando le autorizzazioni per più account vengono concesse direttamente a un principale, solo il destinatario della concessione può visualizzare tali autorizzazioni. L'amministratore del data lake nell' AWS account del destinatario non può visualizzare queste concessioni dirette. + Athena e Redshift Spectrum supportano il controllo degli accessi a livello di colonna, ma solo per l'inclusione, non per l'esclusione. Il controllo degli accessi a livello di colonna non è supportato nei job ETL. AWS Glue + Quando una risorsa viene condivisa con il tuo AWS account, puoi concedere le autorizzazioni sulla risorsa solo agli utenti del tuo account. Non puoi concedere le autorizzazioni sulla risorsa ad altri AWS account, alle organizzazioni (nemmeno alla tua organizzazione) o al `IAMAllowedPrincipals` gruppo. + Non puoi concedere `DROP` o `Super` su un database a un account esterno. + Revoca le autorizzazioni tra account prima di eliminare un database o una tabella. Altrimenti, è necessario eliminare le condivisioni di risorse orfane in. AWS Resource Access Manager **Consulta anche** [Buone pratiche e considerazioni per il controllo degli accessi basato su tag Lake Formation](lf-tag-considerations.md) [`CREATE_TABLE`](lf-permissions-reference.md#perm-create-table)nella sezione [Riferimento alle autorizzazioni di Lake Formation](lf-permissions-reference.md) per ulteriori regole e limitazioni di accesso tra account. # Limitazioni dei ruoli legati ai servizi Un ruolo collegato ai servizi è un tipo speciale di ruolo IAM a cui è collegato direttamente. AWS Lake Formation Questo ruolo dispone di autorizzazioni predefinite che consentono a Lake Formation di eseguire azioni per tuo conto su tutti AWS i servizi. Le seguenti limitazioni si applicano quando si utilizza un ruolo collegato ai servizi (SLR) per registrare le posizioni dei dati con Lake Formation. + Non è possibile modificare le politiche relative ai ruoli collegati ai servizi una volta create. + Un ruolo collegato al servizio non supporta la condivisione di risorse di catalogo crittografate tra account. Le risorse crittografate richiedono autorizzazioni AWS KMS chiave specifiche. I ruoli collegati ai servizi dispongono di autorizzazioni predefinite che non includono la possibilità di utilizzare risorse di catalogo crittografate su più account. + Quando si registrano più sedi Amazon S3, l'utilizzo del ruolo collegato al servizio può far sì che si superino rapidamente i limiti delle policy IAM. Ciò accade perché, con i ruoli collegati ai servizi, AWS scrive la policy per te e la incrementa come un unico grande blocco che include tutte le tue registrazioni. Puoi scrivere politiche gestite dai clienti in modo più efficiente, distribuire le autorizzazioni su più politiche o utilizzare ruoli diversi per regioni diverse. + Amazon EMR su EC2 non può accedere ai dati, registri le posizioni dei dati con ruoli collegati ai servizi. + Le operazioni relative ai ruoli collegati ai servizi aggirano le politiche di controllo del servizio. AWS + Quando registri le posizioni dei dati con un ruolo collegato al servizio, aggiorna le policy IAM con una certa coerenza. Per ulteriori informazioni, consulta la documentazione sulla [risoluzione dei problemi di IAM nella Guida per l'utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html#troubleshoot_general_eventual-consistency). + Non puoi configurare `SET_CONTEXT = TRUE` le impostazioni del data lake Lake Formation quando usi ruoli collegati ai servizi e stai utilizzando IAM Identity Center. Il motivo è che i ruoli collegati ai servizi hanno politiche di fiducia immutabili che sono incompatibili con la propagazione dell'identità affidabile necessaria per il controllo con i principali di IAM Identity Center. `SetContext` # Limitazioni di accesso ai dati tra regioni Lake Formation supporta l'interrogazione su tutte Regioni AWS le tabelle del Data Catalog. Puoi accedere ai dati in una regione da altre regioni utilizzando Amazon Athena Amazon EMR ed AWS Glue ETL creando collegamenti di risorse in altre regioni che puntano ai database e alle tabelle di origine. Con l'accesso alle tabelle tra regioni, puoi accedere ai dati di tutte le regioni senza copiare i dati o i metadati sottostanti nel Data Catalog. Le seguenti limitazioni si applicano all'accesso alle tabelle tra aree geografiche. + Lake Formation non supporta l'interrogazione di tabelle Data Catalog da un'altra regione utilizzando Amazon Redshift Spectrum. + Nella console Lake Formation, le viste del database e della tabella non mostrano i nomi dei database/tabelle Region di origine. + **Per visualizzare l'elenco delle tabelle in un database condiviso di un'altra regione, devi prima creare un collegamento di risorsa al database condiviso, quindi selezionare il collegamento alla risorsa e scegliere Visualizza tabelle.** + Lake Formation non supporta le chiamate ai link di risorse interregionali effettuate dagli utenti SAML. + La funzionalità interregionale di Lake Formation non comporta costi aggiuntivi per i trasferimenti di dati. # Visualizzazioni, considerazioni e limitazioni di Data Catalog Le seguenti considerazioni e limitazioni si applicano alle visualizzazioni del catalogo dati. + Non è possibile creare una vista del Data Catalog dalla console Lake Formation. È possibile creare viste utilizzando AWS CLI o SDK. + È possibile creare viste del catalogo dati da 10 tabelle. È un limite rigido. Le tabelle di riferimento sottostanti per una vista possono appartenere allo stesso database o a database diversi all'interno dello stesso AWS account. + Per ulteriori considerazioni e limitazioni specifiche sulla creazione di viste del catalogo dati utilizzando Redshift, consulta [la sezione Considerazioni e limitazioni delle viste del catalogo dati](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html#data-catalog-views-considerations) nella Amazon Redshift Database Developer Guide. Per Athena, consulta la sezione [Considerazioni e limitazioni delle visualizzazioni del catalogo dati](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html#views-glue-limitations) nella Guida per l'utente di Amazon Athena. + Puoi creare viste del Data Catalog su tabelle registrate con Lake Formation sia in modalità di accesso ibrido che in modalità Lake Formation. Quando si utilizzano le viste di Data Catalog con la modalità di accesso ibrida Lake Formation, si consiglia di assicurarsi che i principali che utilizzano la visualizzazione abbiano attivato le autorizzazioni Lake Formation per le tabelle di base a cui si fa riferimento nella vista senza concedere l'accesso. Ciò garantisce che le tabelle di base non vengano rivelate ai consumatori tramite le autorizzazioni IAM. AWS Glue + Non ci sono restrizioni sulla versione di condivisione tra account per la condivisione delle visualizzazioni. + Le visualizzazioni vengono modificate in modo analogo alle tabelle di Data Catalog, quando si utilizza l'`ALTER VIEW`istruzione per un dialetto di visualizzazione già creato. Non è possibile tornare a una vista precedente perché la versione della vista cambia con le modifiche dei dati sottostanti. È possibile eliminare una versione di visualizzazione e per impostazione predefinita verrà utilizzata la prossima versione più recente disponibile. Quando modifichi la versione di visualizzazione, assicurati che i dati siano sincronizzati con lo schema della versione di visualizzazione selezionata. + Non viene introdotto alcun nuovo Data Catalog APIs . Gli esistenti `CreateTable` `UpdateTable` `DeleteTable` e `GetTable` APIs vengono aggiornati. + Amazon Redshift crea sempre viste con colonne varchar da tabelle con stringhe. È necessario trasmettere colonne di stringhe a varchar con una lunghezza esplicita quando si aggiungono dialetti da altri motori. + La concessione delle autorizzazioni per il data lake all'`All tables`interno di un database comporterà che il beneficiario disponga delle autorizzazioni su tutte le tabelle e le viste all'interno del database. + Non puoi creare viste: + Questo fa riferimento ad altre viste. + Quando la tabella di riferimento è un collegamento a una risorsa. + Quando la tabella di riferimento si trova in un altro account. + Da metastori Hive esterni. + I ruoli di definizione tra account non sono supportati per le viste Redshift Spectrum Dialect. + I collegamenti alle risorse per il dialetto Athena nell'editor di query Athena non sono supportati. Per utilizzare i ruoli di definizione tra account per il dialetto Athena, aggiungi l'account che ospita le tabelle di base come origine dati in Athena. # Limitazioni del filtraggio dei dati Quando concedi le autorizzazioni di Lake Formation su una tabella Data Catalog, puoi includere specifiche di filtraggio dei dati per limitare l'accesso a determinati dati nei risultati delle query e nei motori integrati con Lake Formation. Lake Formation utilizza il filtraggio dei dati per ottenere la sicurezza a livello di colonna, la sicurezza a livello di riga e la sicurezza a livello di cella. Puoi definire e applicare filtri di dati sulle colonne nidificate se i dati di origine contengono strutture nidificate. ## Note e restrizioni per il filtraggio a livello di colonna Esistono tre modi per specificare il filtraggio delle colonne: + Utilizzando filtri di dati + Utilizzando un semplice filtraggio a colonne o un filtraggio a colonne annidate. + Usando. TAGs Il semplice filtraggio delle colonne specifica solo un elenco di colonne da includere o escludere. Sia la console di Lake Formation che l'API AWS CLI supportano il semplice filtraggio delle colonne. Per vedere un esempio, consulta [Grant with Simple Column Filtering](granting-table-permissions.md#simple-column-filter-example). Le seguenti note e restrizioni si applicano al filtraggio delle colonne: + AWS Glue 5.0 o versioni successive supportano il controllo granulare degli accessi tramite Lake Formation solo per le tabelle Apache Hive e Apache Iceberg. + Per concedere `SELECT` con l'opzione grant e il filtraggio delle colonne, è necessario utilizzare un elenco di inclusione, non un elenco di esclusione. Senza l'opzione di concessione, è possibile utilizzare elenchi di inclusione o esclusione. + Per concedere `SELECT` su una tabella con filtro a colonne, devi aver ottenuto l'autorizzazione `SELECT` sulla tabella con l'opzione di concessione e senza alcuna restrizione di riga. Devi avere accesso a tutte le righe. + Se `SELECT` concedi l'opzione di concessione e il filtraggio delle colonne a un principale del tuo account, tale principale deve specificare il filtraggio delle colonne per le stesse colonne o per un sottoinsieme delle colonne concesse quando concede a un altro principale. Se concedi l'opzione `SELECT` di concessione e il filtraggio delle colonne a un account esterno, l'amministratore del data lake dell'account esterno può concedere `SELECT` tutte le colonne a un altro responsabile del proprio account. Tuttavia, anche se `SELECT` su tutte le colonne, tale principale avrà visibilità solo sulle colonne concesse all'account esterno. + Non è possibile applicare il filtraggio delle colonne sulle chiavi di partizione. + A un principale con l'`SELECT`autorizzazione su un sottoinsieme di colonne di una tabella non può essere concessa l'`INSERT`autorizzazione`ALTER`,, `DROP``DELETE`, o per quella tabella. Per un'entità principale con l'`INSERT`autorizzazione`ALTER`, `DROP``DELETE`, o su una tabella, se si concede l'`SELECT`autorizzazione con il filtro delle colonne, l'autorizzazione non ha alcun effetto. Le seguenti note e restrizioni si applicano al filtraggio delle colonne annidate: + È possibile includere o escludere cinque livelli di campi nidificati in un filtro dati. **Example** Col1.Col1\$11.Col1\$11\$11.Col1\$11\$11\$11.Col1\$11\$11\$11\$11\$11 + Non è possibile applicare il filtraggio delle colonne ai campi annidati all'interno delle colonne delle partizioni. + Se lo schema della tabella contiene un nome di colonna di primo livello («cliente»).» address») che presenta lo stesso schema di rappresentazione di un campo nidificato all'interno di un filtro dati (una colonna nidificata con un nome di colonna di primo livello `customer` e un nome di campo nidificato `address` viene specificata come `"customer"."address"` in un filtro dati), non è possibile specificare in modo esplicito l'accesso alla colonna di primo livello o al campo nidificato perché entrambi sono rappresentati utilizzando lo stesso modello negli elenchi. inclusion/exclusion Questo è ambiguo e Lake Formation non può risolvere se stai specificando la colonna di primo livello o il campo annidato. + Se una colonna di primo livello o un campo nidificato contiene una doppia virgoletta all'interno del nome, devi includere una seconda virgoletta quando specifichi l'accesso a un campo nidificato all'interno dell'elenco di inclusione ed esclusione di un filtro di celle di dati. **Example** Esempio di nome di colonna nidificata con virgolette doppie: `a.b.double"quote` **Example** Esempio di rappresentazione di una colonna annidata all'interno di un filtro dati: ` "a"."b"."double""quote"` ## Limitazioni del filtraggio a livello di cella Tieni presente le seguenti note e restrizioni per il filtraggio a livello di riga e di cella. + La sicurezza a livello di cella non è supportata nelle colonne annidate, nelle viste e nei link alle risorse. + Tutte le espressioni supportate nelle colonne di primo livello sono supportate anche nelle colonne nidificate. Tuttavia, **non** è necessario fare riferimento ai campi nidificati nelle colonne di partizione quando si definiscono espressioni nidificate a livello di riga. + La sicurezza a livello di cella è disponibile in tutte le regioni quando si utilizza la versione 3 del motore Athena o Amazon Redshift Spectrum. Per altri servizi, la sicurezza a livello di cella è disponibile solo nelle regioni menzionate in. [Regioni supportate](supported-regions.md) + Le istruzioni `SELECT INTO` non sono supportate. + I `array` tipi di `map` dati e non sono supportati nelle espressioni di filtro di riga. Il tipo di `struct` dati è supportato. + Non esiste un limite al numero di filtri di dati che possono essere definiti su una tabella, ma esiste un limite di 100 filtri di dati per un singolo principale su una tabella. + Per applicare un filtro dati con un'espressione di filtro di riga, è necessario disporre `SELECT` dell'opzione grant su tutte le colonne della tabella. Questa restrizione non si applica agli amministratori degli account esterni quando la concessione è stata concessa all'account esterno. + Se un principale è membro di un gruppo e sia al principale che al gruppo vengono concesse le autorizzazioni su un sottoinsieme di righe, i permessi di riga effettivi del principale sono l'unione dei permessi del principale e dei permessi del gruppo. + I seguenti nomi di colonna sono limitati in una tabella per il filtraggio a livello di riga e di cella: + ctid + oid + xmin + cmin + xmax + cmax + tableoide + inserire xid + elimina xid + importoide + ID univoco per gatti rossi + Se si applica l'espressione di filtro composta da tutte le righe su una tabella contemporaneamente ad altre espressioni di filtro con predicati, l'espressione composta da tutte le righe prevarrà su tutte le altre espressioni di filtro. + Quando le autorizzazioni su un sottoinsieme di righe vengono concesse a un AWS account esterno e l'amministratore del data lake dell'account esterno concede tali autorizzazioni a un principale in quell'account, il predicato di filtro effettivo del principale è l'intersezione tra il predicato dell'account e qualsiasi predicato concesso direttamente al principale. Ad esempio, se l'account dispone delle autorizzazioni di riga con il predicato `dept='hr'` e al principale è stata concessa separatamente l'autorizzazione per`country='us'`, l'account principale ha accesso solo alle righe con `dept='hr'` e`country='us'`. Per ulteriori informazioni sul filtraggio a livello di cella, vedere. [Filtraggio dei dati e sicurezza a livello di cella in Lake Formation](data-filtering.md) Per considerazioni e limitazioni relative all'esecuzione di query su tabelle utilizzando Amazon Redshift Spectrum con policy di sicurezza a livello di riga, consulta [Considerazioni e limitazioni sull'uso delle politiche RLS nella Amazon Redshift Database](https://docs.aws.amazon.com/redshift/latest/dg/t_rls_usage.html) Developer Guide. # Considerazioni e limitazioni della modalità di accesso ibrido La modalità di accesso ibrido offre la flessibilità necessaria per abilitare selettivamente le autorizzazioni di Lake Formation per database e tabelle del tuo. AWS Glue Data Catalog
 Con la modalità di accesso ibrida, ora disponi di un percorso incrementale che ti consente di impostare le autorizzazioni di Lake Formation per un set specifico di utenti senza interrompere le politiche di autorizzazione di altri utenti o carichi di lavoro esistenti. Le seguenti considerazioni e limitazioni si applicano alla modalità di accesso ibrida. **Limitazioni** + **Aggiorna la registrazione delle sedi Amazon S3**: non puoi modificare i parametri di una sede registrata con Lake Formation utilizzando un ruolo collegato al servizio. + **Opzione di attivazione quando si utilizzano i tag LF** — Quando è possibile concedere i permessi di Lake Formation utilizzando i tag LF, è possibile attivare i principali per applicare i permessi di Lake Formation in un passaggio consecutivo scegliendo database e tabelle a cui sono allegati i tag LF. + Accesso in **modalità di accesso ibrido**: l'accesso alla modalità di accesso ibrida in Lake Formation è limitato agli utenti con autorizzazioni di amministratore del data lake o di amministratore di sola lettura. + **Principi di opt-in**: attualmente, solo un ruolo di amministratore del data lake può assegnare i principali alle risorse. + **Attivazione di tutte le tabelle di un database**: nelle concessioni tra account, quando si concedono autorizzazioni e in tutte le tabelle di un database, è necessario attivare anche il database affinché le autorizzazioni funzionino. **Considerazioni** + **Aggiornamento della posizione Amazon S3 registrata con Lake Formation alla modalità di accesso ibrida**: non consigliamo di convertire una posizione dati Amazon S3 già registrata con Lake Formation in modalità di accesso ibrida, sebbene sia possibile farlo. + **Comportamenti delle API quando una posizione dei dati viene registrata in modalità di accesso ibrida** + CreateTable — La località è considerata registrata presso Lake Formation indipendentemente dal flag della modalità di accesso ibrida e dallo stato di attivazione. Pertanto, l'utente richiede l'autorizzazione alla localizzazione dei dati per creare una tabella. + CreatePartition/BatchCreatePartitions/UpdatePartitions(quando la posizione della partizione viene aggiornata in modo che punti alla posizione registrata con hybrid): la posizione Amazon S3 è considerata registrata presso Lake Formation indipendentemente dal flag della modalità di accesso ibrida e dallo stato di attivazione. Pertanto, l'utente richiede l'autorizzazione alla localizzazione dei dati per creare o aggiornare un database. + CreateDatabase/UpdateDatabase (quando la posizione del database viene aggiornata in modo che punti alla posizione registrata in modalità di accesso ibrida): la posizione viene considerata registrata con Lake Formation indipendentemente dal flag della modalità di accesso ibrida e dallo stato di attivazione. Pertanto, l'utente richiede l'autorizzazione alla localizzazione dei dati per creare o aggiornare un database. + UpdateTable (quando una posizione della tabella viene aggiornata in modo che punti alla posizione registrata in modalità di accesso ibrida): la posizione viene considerata registrata con Lake Formation indipendentemente dal flag della modalità di accesso ibrida e dallo stato di attivazione. Pertanto, l'utente richiede l'autorizzazione alla localizzazione dei dati per aggiornare la tabella. Se la posizione della tabella non è aggiornata o punta a una posizione non registrata con Lake Formation, l'utente non richiede l'autorizzazione alla posizione dei dati per aggiornare la tabella. # Limitazioni per l'inserimento dei dati del data warehouse di Amazon Redshift nel AWS Glue Data Catalog Puoi catalogare e gestire l'accesso ai dati analitici nei data warehouse di Amazon Redshift utilizzando il. AWS Glue Data Catalog Si applicano le limitazioni seguenti: + La condivisione tra account non è supportata a livello di catalogo federato. Tuttavia, puoi condividere singoli database e tabelle dall'interno di un catalogo federato tra s. Account AWS + È necessario disporre **delle impostazioni della versione 4 o successiva dell'account Cross** per condividere database o tabelle nel catalogo federato tra Account AWS s. + Il Data Catalog supporta la creazione solo di cataloghi di primo livello. + È possibile aggiornare solo la descrizione dei cataloghi in Redshift Managed Storage (RMS). + L'impostazione delle autorizzazioni per i cataloghi federati, nonché per i database e le tabelle del catalogo federato da raggruppare non è supportata. `IAMAllowedPrincipals` + Le operazioni DDL (Data Definition Language) sul catalogo da motori come Athena, Amazon EMR Spark o altri, inclusa l'impostazione delle configurazioni del catalogo, non sono supportate. + L'esecuzione di operazioni DDL su tabelle RMS utilizzando Athena non è supportata. + La creazione di viste materializzate non è supportata, sia che avvenga tramite Athena, Apache Spark, AWS Glue Data Catalog Amazon Redshift consumer o Amazon Redshift. + Athena non supporta un'esperienza multicatalogo. Può connettersi solo a un singolo catalogo specifico alla volta. Athena non può accedere o eseguire query su più cataloghi contemporaneamente. + Le operazioni di etichettatura e ramificazione sulle tabelle Iceberg tramite Athena e Amazon Redshift non sono supportate. + Time Travel sulle tabelle RMS non è supportato. + I cataloghi a più livelli con tabelle Data Lake non sono supportati. Tutti i dati archiviati in Amazon S3 per l'uso con le tabelle dei data lake devono risiedere nell'impostazione predefinita AWS Glue Data Catalog e non possono essere organizzati in cataloghi a più livelli. + In Amazon Redshift, le condivisioni di dati non vengono aggiunte allo spazio dei nomi registrato. Cluster e namespace sono sinonimi, una volta pubblicato un cluster in, non è possibile aggiungere nuovi dati. AWS Glue Data Catalog + Amazon EMR su EC2 non supporta l'unione tra tabelle RMS e tabelle Amazon S3. Solo EMR Serverless supporta questa funzionalità. + Gli schemi e le tabelle esterni non sono supportati. + Le tabelle RMS sono accessibili solo dall'endpoint di estensione nel catalogo REST di AWS Glue Iceberg. + Le tabelle Hive non sono accessibili dai motori di terze parti collegati al catalogo REST di Iceberg. AWS Glue + Sarà supportato il livello di isolamento read\$1commit sulle tabelle RMS tramite Spark. + I nomi dei database Redshift vengono trattati senza distinzione tra maiuscole e minuscole in AWS Glue Data Catalog, limitati a 128 caratteri e possono essere alfanumerici con trattini (-) e caratteri di sottolineatura (\$1). + I nomi dei cataloghi non fanno distinzione tra maiuscole e minuscole, sono limitati a 50 caratteri e possono essere alfanumerici con trattini (-) e caratteri di sottolineatura (\$1). + Amazon Redshift non supporta l'utilizzo dei comandi GRANT e REVOKE in stile SQL di Lake Formation per gestire le autorizzazioni di accesso alle tabelle pubblicate su. AWS Glue Data Catalog + Le policy di sicurezza a livello di riga e di mascheramento dinamico dei dati collegate al cluster Amazon Redshift del produttore (fonte) non verranno applicate. Invece, le autorizzazioni di accesso definite in Lake Formation verranno applicate ai dati condivisi. + L'esecuzione di operazioni DDL (Data Definition Language) e Data Manipulation Language (DML) sui collegamenti alle tabelle non è supportata. + Se le parole chiave riservate non vengono evase correttamente, si verificheranno errori o errori. + La crittografia dei dati in scenari multicatalogo non è supportata. # Limitazioni dell'integrazione del catalogo S3 Tables Amazon S3 Tables si integra con AWS Glue Data Catalog (Data Catalog) e registra il catalogo come posizione dati di Lake Formation. Puoi configurare questa registrazione dalla console di Lake Formation o utilizzando il servizio APIs. **Nota** Se disponi di una policy basata sulle risorse IAM o S3 Tables che limita gli utenti IAM e i ruoli IAM in base ai tag principali, devi associare gli stessi tag principali al ruolo IAM utilizzato da Lake Formation per accedere ai tuoi dati S3 (ad esempio LakeFormationDataAccessRole) e concedere a questo ruolo le autorizzazioni necessarie. Ciò è necessario affinché la politica di controllo degli accessi basata su tag funzioni correttamente con l'integrazione analitica di S3 Tables. Le seguenti limitazioni si applicano all'integrazione del catalogo S3 Tables con Data Catalog e Lake Formation: + AWS Glue e Lake Formation non supportano i nomi di colonna composti da maiuscole e minuscole e convertono tutti i nomi delle colonne in minuscolo. È necessario verificare che i nomi delle colonne della tabella siano univoci quando vengono convertiti in lettere minuscole. Usa `customer_id` invece di. `customerId` L'uso di nomi di colonna composti da maiuscole e minuscole era supportato solo durante la versione di anteprima. + L' CreateCatalog API non può creare bucket di tabelle in Amazon S3. + L' SearchTables API non può cercare nelle tabelle S3. # I metadati di Hive archiviano: considerazioni e limitazioni sulla condivisione dei dati Con la federazione dei AWS Glue Data Catalog metadati (Data Catalog federation), puoi connettere il Data Catalog a metastore esterni che archiviano i metadati per i tuoi dati Amazon S3 e gestire in modo sicuro le autorizzazioni di accesso ai dati utilizzando. AWS Lake Formation Le seguenti considerazioni e limitazioni si applicano ai database federati creati dai database Hive: **Considerazioni** + **AWS SAM supporto delle applicazioni**: sei responsabile della disponibilità delle risorse applicative che AWS SAM distribuisce (Amazon API Gateway e della funzione Lambda). Assicurati che la connessione tra il metastore AWS Glue Data Catalog e Hive funzioni quando gli utenti eseguono le query. + **Requisiti della versione di Hive metastore**: puoi creare database federati solo utilizzando Apache Hive versione 3 e successive. + **Requisiti del database mappato**: ogni database Hive deve essere mappato su un nuovo database in Lake Formation. + **Supporto federativo a livello di database**: puoi connetterti a Hive metastore solo a livello di database. + **Autorizzazioni su database federati**: le autorizzazioni applicate a un database federato o alle tabelle in un database federato persistono anche quando viene eliminato un database o una tabella di origine. Quando il database o la tabella di origine vengono ricreati, non è necessario concedere nuovamente le autorizzazioni. Quando una tabella federata con autorizzazioni Lake Formation viene eliminata all'origine, le autorizzazioni di Lake Formation sono ancora visibili e puoi revocarle se necessario. Se un utente elimina un database federato, tutte le autorizzazioni corrispondenti vengono perse. Ricreando lo stesso database con lo stesso nome, non verranno ripristinate le autorizzazioni di Lake Formation. Gli utenti dovranno configurare nuovamente le nuove autorizzazioni. + **IAMAllowedAutorizzazioni di gruppo principali** sui database federati: in base a`DataLakeSettings`, Lake Formation potrebbe impostare le autorizzazioni per tutti i database e le tabelle a un gruppo virtuale denominato. `IAMAllowedPrincipal` `IAMAllowedPrincipal`Si riferisce a tutti i responsabili IAM che hanno accesso alle risorse del Data Catalog tramite le politiche principali e le politiche delle risorse IAM. AWS Glue Se queste autorizzazioni esistono su un database o una tabella, a tutti i principali viene concesso l'accesso al database o alla tabella. Tuttavia, Lake Formation non consente `IAMAllowedPrincipal` le autorizzazioni sulle tabelle nei database federati. Quando crei database federati, assicurati di passare il `CreateTableDefaultPermissions` parametro come elenco vuoto. Per ulteriori informazioni, consulta [Modifica delle impostazioni predefinite per il data lake](change-settings.md). + **Unire tabelle nelle query**: puoi unire le tabelle metastore di Hive alle tabelle native di Data Catalog per eseguire le query. **Limitazioni** + **Limitazione alla sincronizzazione dei metadati tra il metastore Hive AWS Glue Data Catalog e il metastore Hive: dopo aver stabilito la connessione al metastore** Hive, è necessario creare un database federato per sincronizzare i metadati nel metastore Hive con il. AWS Glue Data Catalog Le tabelle del database federato vengono sincronizzate in fase di esecuzione quando gli utenti eseguono le query. + **Limitazione alla creazione di nuove tabelle in un database federato**: non sarà possibile creare nuove tabelle in database federati. + **Limitazione delle autorizzazioni dei dati**: il supporto per le autorizzazioni sulle viste delle tabelle dei metastore di Hive non è disponibile. # Limitazioni della condivisione dei dati di Amazon Redshift AWS Lake Formation consente di gestire in modo sicuro i dati in un datashare di Amazon Redshift. Amazon Redshift è un servizio di data warehouse completamente gestito su scala di petabyte nel cloud. AWS Utilizzando la funzionalità di condivisione dei dati, Amazon Redshift ti aiuta a condividere i dati tra di loro. Account AWS Per ulteriori informazioni sulla condivisione dei dati di Amazon Redshift, consulta [Panoramica sulla condivisione dei dati in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/data_sharing_intro.html). Le seguenti note e restrizioni si applicano ai database federati creati da condivisioni di dati Amazon Redshift: + **Requisiti del database mappato**: ogni datashare Amazon Redshift deve essere mappato su un nuovo database in Lake Formation. Ciò è necessario per mantenere nomi di tabella univoci quando la rappresentazione degli oggetti datashare è appiattita nel database Data Catalog. + **Limitazione alla creazione di nuove tabelle in un database federato**: non sarà possibile creare nuove tabelle in database federati. + **Autorizzazioni sui database federati**: le autorizzazioni applicate a un database federato o alle tabelle in un database federato persistono anche quando viene eliminato una tabella di origine o un database. Quando il database o la tabella di origine vengono ricreati, non è necessario concedere nuovamente le autorizzazioni. Quando una tabella federata con autorizzazioni Lake Formation viene eliminata all'origine, le autorizzazioni di Lake Formation saranno ancora visibili e potrai revocarle se necessario. Se un utente elimina un database federato, tutte le autorizzazioni corrispondenti vengono perse. Ricreando lo stesso database con lo stesso nome, non verranno ripristinate le autorizzazioni di Lake Formation. Gli utenti dovranno configurare nuovamente le nuove autorizzazioni. + **IAMAllowedAutorizzazioni di gruppo principali sui database federati**: in base a`DataLakeSettings`, Lake Formation potrebbe impostare le autorizzazioni per tutti i database e le tabelle a un gruppo virtuale denominato. `IAMAllowedPrincipal` `IAMAllowedPrincipal`Si riferisce a tutti i responsabili IAM che hanno accesso alle risorse del Data Catalog tramite le politiche principali e le politiche delle risorse IAM. AWS Glue Se queste autorizzazioni esistono su un database o una tabella, a tutti i principali viene concesso l'accesso al database o alla tabella. Tuttavia, Lake Formation non consente `IAMAllowedPrincipal` le autorizzazioni sulle tabelle nei database federati. Quando crei database federati, assicurati di passare il `CreateTableDefaultPermissions` parametro come elenco vuoto. Per ulteriori informazioni, consulta [Modifica delle impostazioni predefinite per il data lake](change-settings.md). + **Filtraggio dei dati**: in Lake Formation, puoi concedere autorizzazioni su una tabella in un database federato con filtri a livello di colonna e di riga. Tuttavia, non è possibile combinare il filtraggio a livello di colonna e a livello di riga per limitare l'accesso con granularità a livello di cella alle tabelle all'interno di database federati. + **Identificatore di distinzione tra maiuscole** e minuscole: gli oggetti datashare di Amazon Redshift gestiti da Lake Formation supporteranno i nomi delle tabelle e delle colonne solo in lettere minuscole. Non attivare l'identificatore di distinzione tra maiuscole e minuscole per database, tabelle e colonne nelle condivisioni di dati Amazon Redshift, se verranno condivise e gestite utilizzando Lake Formation. + **Supporto per le query**: puoi eseguire query sulle condivisioni di dati Amazon Redshift gestite da Lake Formation con Amazon Redshift. Athena non supporta l'interrogazione di datashare Amazon Redshift gestite da Lake Formation. Per ulteriori informazioni sulle limitazioni quando si lavora con le condivisioni di dati in Amazon Redshift, [consulta Limitazioni per la condivisione dei dati](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html#limitations-datashare) nella Amazon Redshift Database Developer Guide. # Limitazioni dell'integrazione di IAM Identity Center Con AWS IAM Identity Center, puoi connetterti ai provider di identità (IdPs) e gestire centralmente l'accesso per utenti e gruppi a tutti i servizi di AWS analisi. Puoi configurarlo AWS Lake Formation come applicazione abilitata in IAM Identity Center e gli amministratori del data lake possono concedere autorizzazioni granulari a utenti e gruppi autorizzati sulle risorse. AWS Glue Data Catalog Le seguenti limitazioni si applicano all'integrazione di Lake Formation con IAM Identity Center: + Non puoi assegnare utenti e gruppi di IAM Identity Center come amministratori di data lake o amministratori di sola lettura in Lake Formation. Gli utenti e i gruppi di IAM Identity Center possono interrogare le risorse crittografate del Data Catalog se utilizzi un ruolo IAM che AWS Glue può assumere per tuo conto per la crittografia e la decrittografia del Data Catalog. AWS le chiavi gestite non supportano la propagazione affidabile delle identità. + Gli utenti e i gruppi di IAM Identity Center possono richiamare solo le operazioni API elencate nella `AWSIAMIdentityCenterAllowListForIdentityContext` policy fornita da IAM Identity Center. + Lake Formation consente ai ruoli IAM di account esterni di agire come portatori per conto degli utenti e dei gruppi di IAM Identity Center per l'accesso alle risorse del Data Catalog, ma le autorizzazioni possono essere concesse solo sulle risorse del Data Catalog all'interno dell'account proprietario. Se provi a concedere le autorizzazioni agli utenti e ai gruppi di IAM Identity Center sulle risorse Data Catalog in un account esterno, Lake Formation genera il seguente errore: «Le sovvenzioni tra account non sono supportate per il principale». + Quando si utilizza Lake Formation con IAM Identity Center, la configurazione di assegnazione dell'applicazione è impostata come `false` impostazione predefinita. Se modifichi questa configurazione direttamente tramite l'[API IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_PutApplicationAssignmentConfiguration.html), devi quindi gestire tutte le assegnazioni delle applicazioni manualmente utilizzando l'API. Lake Formation non sincronizza o gestisce automaticamente le modifiche alle assegnazioni effettuate al di fuori dei suoi flussi di lavoro standard, il che può influire sui modelli di accesso e sui flussi di autorizzazione all'interno dell'ambiente di data lake. # Buone pratiche e considerazioni per il controllo degli accessi basato su tag Lake Formation È possibile creare, gestire e assegnare LF-tags per controllare l'accesso ai database, alle tabelle e alle colonne del Data Catalog. Prendi in considerazione le seguenti best practice quando utilizzi il controllo degli accessi basato su tag Lake Formation: + Tutti i tag LF devono essere predefiniti prima di poter essere assegnati alle risorse del Data Catalog o concessi ai responsabili. L'amministratore del data lake può delegare le attività di gestione dei tag creando creatori di *tag LF* con le autorizzazioni IAM richieste. Gli ingegneri e gli analisti dei dati decidono le caratteristiche e le relazioni dei tag LF. I creatori di LF-tag creano quindi e mantengono i tag LF in Lake Formation. + È possibile assegnare più LF-tag alle risorse del Data Catalog. È possibile assegnare un solo valore per una particolare chiave a una particolare risorsa. Ad esempio, è possibile assegnare`module=Orders`, `region=West``division=Consumer`, e così via a un database, una tabella o una colonna. Non puoi `module=Orders,Customers` assegnare. + Non è possibile assegnare tag LF alle risorse quando si crea la risorsa. È possibile aggiungere tag LF solo alle risorse esistenti. + È possibile concedere espressioni LF-Tag, non solo singoli tag LF, a un principale. Un'espressione LF-Tag ha un aspetto simile alla seguente (in pseudo-codice). ``` module=sales AND division=(consumer OR commercial) ``` *Un principale a cui è concessa questa espressione LF-Tag può accedere solo alle risorse del Data Catalog (database, tabelle e colonne) assegnate e a una delle due opzioni. `module=sales`* `division=consumer` `division=commercial` Se desideri che il principale sia in grado di accedere a risorse che dispongono `module=sales` *o meno* `division=commercial` di includerle entrambe nella stessa concessione. Fai due sovvenzioni, una per `module=sales` e una per`division=commercial`. L'espressione più semplice del tag LF è costituita da un solo tag LF, ad esempio. `module=sales` + Un principale a cui sono concesse le autorizzazioni per un tag LF con più valori può accedere alle risorse del Data Catalog con uno di questi valori. Ad esempio, se a un utente viene concesso un tag LF con key= `module` e values=`orders,customers`, l'utente ha accesso alle risorse assegnate o. `module=orders` `module=customers` + È necessario disporre dell'`Grant with LF-Tag expressions`autorizzazione per concedere le autorizzazioni relative ai dati sulle risorse del Catalogo dati utilizzando il metodo LF-TBAC. L'amministratore del data lake e il creatore di LF-Tag ricevono implicitamente questa autorizzazione. Un principale che dispone dell'`Grant with LFTag expressions`autorizzazione può concedere le autorizzazioni relative ai dati sulle risorse utilizzando: + il metodo di risorsa denominato + il metodo LF-TBAC, ma utilizzando solo la stessa espressione LF-TAG Ad esempio, supponiamo che l'amministratore del data lake conceda la seguente concessione (in pseudo-codice). ``` GRANT (SELECT ON TABLES) ON TAGS module=customers, region=west,south TO user1 WITH GRANT OPTION ``` In questo caso, `user1` può concedere `SELECT` tabelle ad altri principali utilizzando il metodo LF-TBAC, ma solo con l'espressione LF-TAG completa. `module=customers, region=west,south` + Se a un principale vengono concesse le autorizzazioni su una risorsa sia con il metodo LF-TBAC che con il metodo della risorsa denominata, i permessi che il principale ha sulla risorsa sono l'unione dei permessi concessi con entrambi i metodi. + Lake Formation supporta la concessione `DESCRIBE` e `ASSOCIATE` l'eliminazione dei tag LF tra gli account e la concessione di autorizzazioni sulle risorse del Data Catalog tra gli account utilizzando il metodo LF-TBAC. In entrambi i casi, il principale è l'ID dell'account. AWS **Nota** Lake Formation supporta sovvenzioni tra account a organizzazioni e unità organizzative utilizzando il metodo LF-TBAC. **Per utilizzare questa funzionalità, è necessario aggiornare le impostazioni della versione di **Cross account alla versione 3**.** Per ulteriori informazioni, consulta [Condivisione dei dati tra account in Lake Formation](cross-account-permissions.md). + Le risorse del Data Catalog create in un account possono essere etichettate solo utilizzando i tag LF creati nello stesso account. I tag LF creati in un account non possono essere associati a risorse condivise di un altro account. + L'utilizzo del controllo degli accessi basato su tag Lake Formation (LF-TBAC) per concedere l'accesso tra account alle risorse del Data Catalog richiede aggiunte alla politica delle risorse del Data Catalog per il tuo account. AWS Per ulteriori informazioni, consulta [Prerequisiti](cross-account-prereqs.md). + Le chiavi LF-Tag e i valori LF-Tag non possono superare i 50 caratteri di lunghezza. + Il numero massimo di tag LF che possono essere assegnati a una risorsa del Data Catalog è 50. + I seguenti limiti sono limiti flessibili: + Il numero massimo di tag LF che è possibile creare è 1000. + Il numero massimo di valori che possono essere definiti per un LF-tag è 1000. + Le chiavi e i valori dei tag vengono convertiti in lettere minuscole quando vengono memorizzati. + È possibile assegnare un solo valore per un tag LF a una particolare risorsa. + Se vengono concessi più LF-tag a un principale con un'unica concessione, il principale può accedere solo alle risorse del Data Catalog che contengono tutti i tag LF. + Se la valutazione di un'espressione LF-Tag comporta l'accesso solo a un sottoinsieme di colonne della tabella, ma l'autorizzazione Lake Formation concessa in caso di corrispondenza è una delle autorizzazioni che richiedevano l'accesso completo alla colonna, vale a dire,, o `Alter` `Drop` `Insert``Delete`, allora nessuna di queste autorizzazioni viene concessa. Invece, viene concesso solo. `Describe` Se l'autorizzazione concessa è `All` (`Super`), allora solo `Select` e `Describe` vengono concesse. + I wildcard non vengono utilizzati con i tag LF. Per assegnare un tag LF a tutte le colonne di una tabella, si assegna il tag LF alla tabella e tutte le colonne della tabella ereditano il tag LF. Per assegnare un tag LF a tutte le tabelle di un database, si assegna il tag LF al database e tutte le tabelle del database ereditano quel tag LF. + È possibile creare fino a 1000 espressioni di tag LF in un account. + È possibile utilizzare fino a 50 espressioni di tag LF per concedere autorizzazioni a un principale sulle risorse del Data Catalog. + Quando si concedono o si revocano le autorizzazioni su un'espressione di tag LF in linea, la dimensione dell'espressione del tag LF non può superare i 900 byte. Per concedere i permessi su espressioni di tag LF più grandi, utilizzate le espressioni di tag LF salvate. Per ulteriori informazioni, consulta [Creazione di espressioni con tag LF](TBAC-creating-tag-expressions.md). + Per aggiungere LF-Tag ai cataloghi federati Redshift esistenti creati prima della versione di disponibilità generale del supporto LF-Tag per i cataloghi federati, è necessario contattare il team di supporto per ricevere assistenza. AWS # Considerazioni, limitazioni e aree supportate sul controllo degli accessi basato sugli attributi Le seguenti considerazioni e limitazioni si applicano al controllo degli accessi basato sugli attributi (ABAC). + ABAC non supporta la concessione dell'accesso tramite le politiche LF-tag. + Le autorizzazioni concesse non sono disponibili con ABAC. + ABAC non supporta la concessione di autorizzazioni agli utenti di IAM Identity Center. + Quando si utilizzano le sovvenzioni ABAC su una tabella in Lake Formation, Lake Formation non concede `DESCRIBE` autorizzazioni al database o al catalogo principale. Ciò differisce dagli scenari non ABAC, in cui Lake Formation fornisce `DESCRIBE` autorizzazioni implicite alle risorse principali. + Tutti i principali con la chiave `AmazonDataZoneProject` tag vengono sempre considerati come se fossero stati inseriti in Lake Formation per tutte le risorse del Data Catalog. + ABAC supporta solo gli attributi di stringa.