As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Práticas recomendadas, considerações e limitações do Lake Formation Use esta seção para encontrar rapidamente as práticas recomendadas, considerações e limitações no AWS Lake Formation. Consulte [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/lake-formation.html#limits_lake-formation) para conhecer o número máximo de recursos de serviço ou operações da Conta da AWS. **Topics** + [ # Práticas recomendadas e considerações sobre compartilhamento de dados entre contas ](cross-account-notes.md) + [ # Limitações de perfis vinculadas a serviços ](service-linked-role-limitations.md) + [ # Limitações de acesso aos dados entre regiões ](x-region-considerations.md) + [ # Considerações e limitações das visualizações do catálogo de dados ](views-notes.md) + [ # Limitações de filtragem de dados ](data-filtering-notes.md) + [ # Considerações e limitações do modo de acesso híbrido ](notes-hybrid.md) + [ # Limitações para trazer dados do armazém de dados do Amazon Redshift para o AWS Glue Data Catalog ](notes-ns-catalog.md) + [ # Limitações da integração do catálogo do S3 Tables ](notes-s3-catalog.md) + [ # Considerações e limitações do compartilhamento de dados de armazenamento de metadados do Hive ](notes-hms.md) + [ # Limitações do compartilhamento de dados do Amazon Redshift ](notes-rs-datashare.md) + [ # Limitações da integração com o Centro de Identidade do IAM ](identity-center-lf-notes.md) + [ # Considerações e práticas recomendadas de controle de acesso com base em tags do Lake Formation ](lf-tag-considerations.md) + [ # Considerações sobre controle de acesso por atributo, limitações e regiões aceitas ](abac-considerations.md) # Práticas recomendadas e considerações sobre compartilhamento de dados entre contas Os recursos de várias contas do Lake Formation permitem que os usuários compartilhem com segurança lagos de dados distribuídos em várias AWS organizações ou diretamente com os diretores do IAM em outra conta Contas da AWS, fornecendo acesso refinado aos metadados do Catálogo de Dados e aos dados subjacentes. Pense nas seguintes práticas recomendadas ao usar o compartilhamento de dados entre contas do Lake Formation: + Não há limite para o número de concessões de permissão do Lake Formation que você pode conceder aos diretores em sua própria AWS conta. No entanto, o Lake Formation usa a capacidade AWS Resource Access Manager (AWS RAM) para concessões entre contas que sua conta pode fazer com o método de recurso nomeado. Para maximizar a AWS RAM capacidade, siga estas melhores práticas para o método de recurso nomeado: + Use o novo modo de concessão entre contas (**versão 3** e superior em **Configurações de versão entre contas**) para compartilhar um recurso com um externo Conta da AWS. Para obter mais informações, consulte [Como atualizar as configurações da versão de compartilhamento de dados entre contas](optimize-ram.md). + Organize AWS contas em organizações e conceda permissões a organizações ou unidades organizacionais. Uma concessão para uma organização ou unidade organizacional conta como apenas uma concessão. A concessão para organizações ou unidades organizacionais também elimina a necessidade de aceitar um convite AWS Resource Access Manager (AWS RAM) de compartilhamento de recursos para a concessão. Para obter mais informações, consulte [Acessar e visualizar tabelas e bancos de dados compartilhados do catálogo de dados](viewing-shared-resources.md). + Em vez de conceder permissões em várias tabelas individuais do banco de dados, use o curinga especial **Todas as tabelas** para conceder permissões em todas as tabelas do banco de dados. A concessão em **Todas as tabelas** conta como uma única concessão. Para obter mais informações, consulte [Conceder permissões nos recursos do Catálogo de Dados](granting-catalog-permissions.md). **nota** Para obter mais informações sobre como solicitar um limite maior para o número de compartilhamentos de recursos em AWS RAM, consulte [cotas AWS de serviço](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) no. *Referência geral da AWS* + Você deve criar um link de recurso para um banco de dados compartilhado para que esse banco de dados apareça nos editores de consulta Amazon Athena e no Amazon Redshift Spectrum. Da mesma forma, para poder consultar tabelas compartilhadas usando o Athena e o Redshift Spectrum, você deve criar links de recursos para as tabelas. Em seguida, os links de recursos aparecem na lista de tabelas dos editores de consulta. Em vez de criar links de recursos para várias tabelas individuais para consulta, você pode usar o curinga **Todas as tabelas** para conceder permissões em todas as tabelas em um banco de dados. Em seguida, ao criar um link de recurso para esse banco de dados e selecionar esse link de recurso de banco de dados no editor de consultas, você terá acesso a todas as tabelas desse banco de dados para sua consulta. Para obter mais informações, consulte [Criação de links de recursos](creating-resource-links.md). + Quando você compartilha recursos diretamente com principais em outra conta, a entidade principal do IAM na conta do destinatário pode não ter permissão para criar links de recursos para poder consultar as tabelas compartilhadas usando o Athena e o Amazon Redshift Spectrum. Em vez de criar um link de recurso para cada tabela compartilhada, o administrador do data lake pode criar um banco de dados provisório e conceder a permissão `CREATE_TABLE` ao grupo `ALLIAMPrincipal`. Em seguida, todas as entidades principais do IAM na conta do destinatário podem criar links de recursos no banco de dados de espaços reservados, e começar a consultar as tabelas compartilhadas. Veja o exemplo de comando CLI para conceder permissões para `ALLIAMPrincipals` em [Conceder permissões de banco de dados usando o método de recurso nomeado](granting-database-permissions.md). + Quando as permissões entre contas são concedidas diretamente a uma entidade principal, somente o destinatário da concessão pode visualizar essas permissões. O administrador do data lake na conta da AWS do destinatário não pode visualizar essas concessões diretas. + O Athena e o Redshift Spectrum oferecem suporte ao controle de acesso em nível de coluna, mas somente para inclusão, não exclusão. O controle de acesso em nível de coluna não é suportado em trabalhos de ETL no AWS Glue. + Quando um recurso é compartilhado com sua AWS conta, você pode conceder permissões sobre o recurso somente aos usuários da sua conta. Você não pode conceder permissões sobre o recurso para outras AWS contas, para organizações (nem mesmo para sua própria organização) ou para o `IAMAllowedPrincipals` grupo. + Não é possível conceder `DROP` ou `Super` em um banco de dados a uma conta externa. + Revogue as permissões entre contas antes de excluir um banco de dados ou uma tabela. Caso contrário, você deverá excluir compartilhamentos de recursos órfãos em. AWS Resource Access Manager **Consulte também** [Considerações e práticas recomendadas de controle de acesso com base em tags do Lake Formation](lf-tag-considerations.md) [`CREATE_TABLE`](lf-permissions-reference.md#perm-create-table) na seção [Referência de permissões do Lake Formation](lf-permissions-reference.md) para obter mais regras e limitações de acesso entre contas. # Limitações de perfis vinculadas a serviços Uma função vinculada ao serviço é um tipo especial de função do IAM vinculada diretamente a. AWS Lake Formation Essa função tem permissões predefinidas que permitem que a Lake Formation realize ações em seu nome em todos AWS os serviços. As limitações a seguir se aplicam ao usar um perfil vinculado a serviços (SLR) para registrar locais de dados no Lake Formation. + Não é possível modificar políticas de perfil vinculado a serviços depois de criadas. + Um perfil vinculado a serviços não aceita o compartilhamento criptografado de recursos de catálogo entre contas. Recursos criptografados exigem permissões de AWS KMS chave específicas. Os perfis vinculados a serviços têm permissões predefinidas que não incluem a capacidade de trabalhar com recursos de catálogo criptografados em todas as contas. + Ao registrar vários locais do Amazon S3, o uso do perfil vinculado a serviços pode fazer com que você exceda rapidamente os limites da política do IAM. Isso acontece porque, com funções vinculadas a serviços, AWS escreve a política para você e ela é incrementada como um grande bloco que inclui todos os seus registros. Você pode criar políticas gerenciadas pelo cliente com maior eficiência, distribuir permissões em várias políticas ou usar perfis diferentes para regiões distintas. + O Amazon EMR no EC2 não consegue acessar dados a menos que você registre os locais de dados com perfis vinculados a serviços. + As operações de função vinculadas ao serviço ignoram suas AWS políticas de controle de serviços. + Quando você registra locais de dados com um perfil vinculado a serviços, ele atualiza as políticas do IAM com consistência eventual. Para acessar mais informações, consulte a documentação de [solução de problemas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html#troubleshoot_general_eventual-consistency) no Guia do usuário do IAM. + Não é possível definir `SET_CONTEXT = TRUE` nas configurações de data lake do Lake Formation ao usar perfis vinculados a serviços e está usando o Centro de Identidade do IAM. O motivo é que os perfis vinculados a serviços têm políticas de confiança imutáveis que são incompatíveis com a propagação de identidade confiável necessária para a auditoria `SetContext` com as entidades principais do Centro de Identidade do IAM. # Limitações de acesso aos dados entre regiões O Lake Formation aceita a consulta de tabelas do catálogo de dados entre Regiões da AWS. Você pode acessar dados em uma região de outras regiões usando o Amazon Athena Amazon EMR e o AWS Glue ETL criando links de recursos em outras regiões apontando para os bancos de dados e tabelas de origem. Com o acesso à tabela entre regiões, você pode acessar dados entre regiões sem copiar os dados subjacentes ou os metadados no catálogo de dados. As limitações a seguir se aplicam ao acesso a tabelas entre regiões. + O Lake Formation não suporta a consulta de tabelas do catálogo de dados de outra região usando o Amazon Redshift Spectrum. + No console do Lake Formation, as visualizações do banco de dados e da tabela não mostram os nomes dos bancos de dados/tabelas da região de origem. + Para exibir a lista de tabelas em um banco de dados compartilhado de outra região, você precisa primeiro criar um link de recurso para o banco de dados compartilhado, depois selecionar o link do recurso e escolher **Exibir tabelas**. + O Lake Formation não é compatível com chamadas de links de recursos entre regiões. + O recurso entre regiões do Lake Formation não envolve cobranças adicionais pelas transferências de dados. # Considerações e limitações das visualizações do catálogo de dados Estas são considerações e limitações que se aplicam às visualizações do catálogo de dados. + Não é possível criar uma visualização do Data Catalog no console do Lake Formation. Você pode criar visualizações usando o AWS CLI ou SDK. + É possível criar visualizações do Data Catalog em dez tabelas. Trata-se de um limite fixo. As tabelas de referência subjacentes de uma visualização podem pertencer ao mesmo banco de dados ou a bancos de dados diferentes na mesma AWS conta. + Para outras considerações e limitações específicas sobre a criação de visualizações do Data Catalog usando o Redshift, consulte a seção [Considerações e limitações das visualizações do Data Catalog](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html#data-catalog-views-considerations) no Guia do desenvolvedor do banco de dados Amazon Redshift. Para o Athena, consulte a seção [Considerações e limitações das visualizações do Data Catalog](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html#views-glue-limitations) no Guia do usuário do Amazon Athena. + Você pode criar visualizações do Catálogo de Dados em tabelas registradas no Lake Formation no modo de acesso híbrido e no modo do Lake Formation. Ao usar as visualizações do Catálogo de Dados com o modo de acesso híbrido do Lake Formation, é recomendável garantir que as entidades principais de consumo da visualização aceitem as permissões do Lake Formation para as tabelas de base referidas na visualização sem conceder acesso. Isso garante que as tabelas base não sejam reveladas aos consumidores por meio de permissões AWS Glue do IAM. + Não há restrições na versão de compartilhamento entre contas para compartilhar visualizações. + As visualizações são versionadas da mesma forma que as tabelas do Catálogo de Dados quando você usa a instrução `ALTER VIEW` para um dialeto de visualização já criado. Não é possível reverter para uma visualização anterior porque a versão da visualização muda com as alterações dos dados subjacentes. Você pode excluir uma versão de visualização e ela será padronizada para a próxima versão mais recente disponível. Ao alterar a versão da visualização, seus dados devem estar sincronizados com o esquema da versão de visualização selecionada. + Nenhum novo catálogo APIs de dados foi introduzido. Os existentes`CreateTable`,`UpdateTable`, `DeleteTable` e `GetTable` APIs são atualizados. + O Amazon Redshift sempre cria visualizações com colunas varchar com base em tabelas com strings. É necessário converter colunas de string em varchar com um tamanho explícito ao adicionar dialetos de outros mecanismos. + Conceder permissões de data lake a `All tables` em um banco de dados resultará em permissões do favorecido em todas as tabelas e visualizações do banco de dados. + Não é possível criar visualizações: + Isso faz referência a outras visualizações. + Quando a tabela de referência é um link de recurso. + Quando a tabela de referência está em outra conta. + De metastores externos do Hive. + As funções de definição entre contas não são suportadas nas visualizações do Redshift Spectrum Dialect. + Não há suporte para links de recursos para o dialeto Athena no editor de consultas do Athena. Para usar funções de definição de contas cruzadas para o dialeto Athena, adicione a conta que hospeda as tabelas base como uma fonte de dados no Athena. # Limitações de filtragem de dados Ao conceder permissões do Lake Formation em uma tabela do catálogo de dados, você pode incluir especificações de filtragem de dados para restringir o acesso a determinados dados nos resultados da consulta e nos mecanismos integrados ao Lake Formation. O Lake Formation usa a filtragem de dados para obter segurança por coluna, segurança por linha e segurança por célula. Será possível definir e aplicar filtros de dados em colunas aninhadas se os dados de origem contiverem estruturas aninhadas. ## Notas e restrições para filtragem em nível de coluna Há três maneiras de especificar a filtragem de colunas: + Usando filtros de dados + Usando filtragem de colunas simples ou filtragem de colunas aninhada. + Usando TAGs. A filtragem simples de colunas apenas especifica uma lista de colunas a serem incluídas ou excluídas. Tanto o console do Lake Formation quanto a API AWS CLI oferecem suporte à filtragem simples de colunas. Para ver um exemplo, consulte [Grant with Simple Column Filtering](granting-table-permissions.md#simple-column-filter-example). As seguintes notas e restrições se aplicam à filtragem de colunas: + AWS Glue 5.0 ou superior suporta controle de acesso refinado via Lake Formation somente para tabelas Apache Hive e Apache Iceberg. + Para conceder com a opção `SELECT` e a filtragem de colunas, você deve usar uma lista de inclusão, não uma lista de exclusão. Sem a opção de concessão, você pode usar listas de inclusão ou exclusão. + Para conceder `SELECT` em uma tabela com filtragem de colunas, você deve ter recebido a opção de concessão `SELECT` na tabela e sem nenhuma restrição de linha. Você deve ter acesso a todas as linhas. + Se você conceder com a opção `SELECT` e a filtragem de colunas a uma entidade principal em sua conta, essa entidade principal deverá especificar a filtragem de colunas para as mesmas colunas ou um subconjunto das colunas concedidas ao conceder a outra entidade principal. Se você conceder com a opção `SELECT` e a filtragem de colunas a uma conta externa, o administrador do data lake na conta externa poderá conceder `SELECT` a todas as colunas a outra entidade principal em sua conta. No entanto, mesmo com todas as colunas com `SELECT`, esse entidade principal terá visibilidade somente nas colunas concedidas à conta externa. + Você não pode aplicar a filtragem de colunas nas chaves de partição. + Uma entidade principal com a permissão `SELECT` em um subconjunto de colunas em uma tabela não pode receber a permissão `ALTER`, `DROP`, `DELETE`, ou `INSERT` nessa tabela. Para uma entidade principal com a permissão `ALTER`, `DROP`, `DELETE`, ou `INSERT` em uma tabela, se você conceder a permissão `SELECT` com a filtragem de colunas, ela não terá efeito. As seguintes notas e restrições se aplicam à filtragem de colunas aninhadas: + É possível incluir ou excluir cinco níveis de campos aninhados em um filtro de dados. **Example** Col1.Col1\$11.Col1\$11\$11.Col1\$11\$11\$11.Col1\$11\$11\$11\$11 + Não é possível aplicar a filtragem de colunas em campos aninhados em colunas de partição. + Se o esquema da tabela contiver um nome de coluna de nível superior (“cliente”.” address”) que tem o mesmo padrão de representação de campo aninhado em um filtro de dados (uma coluna aninhada com um nome de coluna de nível superior `customer` e um nome de campo aninhado `address` é especificado como `"customer"."address"` em um filtro de dados), você não pode especificar explicitamente o acesso à coluna de nível superior ou ao campo aninhado porque ambos são representados usando o mesmo padrão nas listas. inclusion/exclusion Isso é ambíguo, e o Lake Formation não poderá resolver se você estiver especificando a coluna de nível superior ou o campo aninhado. + Se uma coluna de nível superior ou um campo aninhado contiver aspas duplas no nome, será necessário incluir uma segunda aspa dupla ao especificar o acesso a um campo aninhado na lista de inclusão e exclusão de um filtro de células de dados. **Example** Exemplo de nome de coluna aninhada com aspas duplas: `a.b.double"quote` **Example** Exemplo de representação de coluna aninhada em um filtro de dados: ` "a"."b"."double""quote"` ## Limitações de filtragem no nível de célula Tenha em mente as seguintes notas e restrições para filtragem em nível de linha e de célula: + Em colunas aninhadas, visualizações e links de recurso, não é possível usar a segurança no nível de célula. + Todas as expressões aceitas em colunas de nível superior também são aceitas em colunas aninhadas. No entanto, os campos aninhados em colunas de partição **NÃO** devem ser referenciados ao definir expressões aninhadas em nível de linha. + A segurança por célula está disponível em todas as regiões ao usar o Athena Engine versão 3 ou o Amazon Redshift Spectrum. Para outros serviços, a segurança por célula só está disponível nas regiões mencionadas em [Regiões aceitas](supported-regions.md). + As instruções `SELECT INTO` não são compatíveis. + Os tipos de dados `array` e `map` não são compatíveis com expressões de filtro de linha. O tipo de dados `struct` é aceito. + Não há limite para o número de filtros de dados que podem ser definidos em uma tabela, mas há um limite de cem filtros de dados para uma única entidade principal em uma tabela. + Para aplicar um filtro de dados com uma expressão de filtro de linha, você deve ter a opção `SELECT` de concessão em todas as colunas da tabela. Essa restrição não se aplica a administradores em contas externas quando a concessão foi feita para a conta externa. + Se uma entidade principal for membro de um grupo e tanto a entidade principal quanto o grupo receberem permissões em um subconjunto de linhas, as permissões de linha efetivas da entidade principal são a união das permissões do entidade principal e das permissões do grupo. + Os seguintes nomes de colunas são restritos em uma tabela para filtragem em nível de linha e de célula: + ctid + oid + xmin + cmin + xmax + cmax + tableoid + insertxid + deletexid + importoid + redcatuniqueid + Se você aplicar a expressão de filtro de todas as linhas em uma tabela simultaneamente com outras expressões de filtro com predicados, a expressão de todas as linhas prevalecerá sobre todas as outras expressões de filtro. + Quando as permissões em um subconjunto de linhas são concedidas a uma AWS conta externa e o administrador do data lake da conta externa concede essas permissões a um principal nessa conta, o predicado de filtro efetivo do principal é a interseção do predicado da conta com qualquer predicado concedido diretamente ao principal. Por exemplo, se a conta tiver permissões de linha com o predicado `dept='hr'` e a entidade principal tiver recebido a permissão `country='us'` separadamente, a entidade principal terá acesso somente às linhas com `dept='hr'` e `country='us'`. Para obter mais informações sobre a filtragem em nível de célula, consulte [Filtragem de dados e segurança por célula no Lake Formation](data-filtering.md). Para analisar considerações e limitações ao consultar tabelas usando o Amazon Redshift Spectrum com políticas de segurança em nível de linha, consulte [Considerações e limitações ao usar políticas de RLS](https://docs.aws.amazon.com/redshift/latest/dg/t_rls_usage.html) no Guia do desenvolvedor do banco de dados Amazon Redshift. # Considerações e limitações do modo de acesso híbrido O modo de acesso híbrido oferece a flexibilidade de habilitar seletivamente as permissões do Lake Formation para bancos de dados e tabelas no seu AWS Glue Data Catalog.
 Com o modo de acesso híbrido, agora você tem um caminho incremental que permite definir permissões do Lake Formation para um conjunto específico de usuários sem interromper as políticas de permissão de outros usuários ou workloads existentes. As considerações e limitações a seguir se aplicam ao modo de acesso híbrido. **Limitações** + **Atualizar o registro de localização do Amazon S3** – Você não pode editar parâmetros de um local registrado no Lake Formation usando uma função vinculada ao serviço. + **Opção de ativação ao usar tags do LF** – Quando você pode conceder permissões do Lake Formation usando tags do LF, você pode optar por entidades principais para aplicar as permissões do Lake Formation em uma etapa consecutiva, escolhendo bancos de dados e tabelas com tags do LF anexadas. + **Acesso ao modo de acesso híbrido**: o acesso ao modo de acesso híbrido no Lake Formation é limitado a usuários com permissões de administrador do data lake ou administrador somente leitura. + **Optar por entidades principais** – Atualmente, somente uma função de administrador de data lake pode optar por entidades principais para recursos. + **Aceitar todas as tabelas em um banco de dados**: em concessões entre contas, ao conceder permissões e aceitar todas as tabelas em um banco de dados, é necessário aceitar o banco de dados também para que as permissões funcionem. **Considerações** + **Atualização da localização do Amazon S3 registrada no Lake Formation para o modo de acesso híbrido** – Não recomendamos converter uma localização de dados do Amazon S3 que já esteja registrada no Lake Formation para o modo de acesso híbrido, embora isso possa ser feito. + **Comportamentos da API quando um local de dados é registrado no modo de acesso híbrido** + CreateTable — O local é considerado registrado no Lake Formation, independentemente da bandeira do modo de acesso híbrido e do status de opt-in. Assim, o usuário precisa da permissão de localização dos dados para criar uma tabela. + CreatePartition/BatchCreatePartitions/UpdatePartitions(quando a localização da partição é atualizada para apontar para a localização registrada com híbrido) — A localização do Amazon S3 é considerada registrada no Lake Formation, independentemente da bandeira do modo de acesso híbrido e do status de aceitação. Assim, o usuário precisa da permissão de localização de dados para criar ou atualizar um banco de dados. + CreateDatabase/UpdateDatabase (quando a localização do banco de dados é atualizada para apontar para a localização registrada no modo de acesso híbrido) — A localização é considerada registrada no Lake Formation, independentemente da bandeira do modo de acesso híbrido e do status de ativação. Assim, o usuário precisa da permissão de localização de dados para criar ou atualizar um banco de dados. + UpdateTable (quando a localização de uma tabela é atualizada para apontar para a localização registrada no modo de acesso híbrido) — A localização é considerada registrada no Lake Formation, independentemente da bandeira do modo de acesso híbrido e do status de ativação. Assim, o usuário precisa de permissão de localização de dados para atualizar a tabela. Se a localização da tabela não for atualizada ou estiver apontando para uma localização que não esteja registrada no Lake Formation, o usuário não precisará da permissão de localização de dados para atualizar a tabela. # Limitações para trazer dados do armazém de dados do Amazon Redshift para o AWS Glue Data Catalog É possível catalogar e gerenciar o acesso aos dados de analytics nos data warehouses do Amazon Redshift usando o AWS Glue Data Catalog. As limitações a seguir se aplicam a: + O compartilhamento entre contas não é aceito em nível de catálogo federado. Contudo, você pode compartilhar bancos de dados e tabelas individuais de dentro de um catálogo federado entre Conta da AWS s. + Você deve ter **as configurações de versão da conta cruzada** versão 4 ou superior para compartilhar bancos de dados ou tabelas no catálogo federado entre Conta da AWS s. + O Data Catalog comporta a criação somente de catálogos de nível superior. + Você só pode atualizar a descrição de catálogos no Redshift Managed Storage (RMS). + A configuração de permissões em catálogos federados, bem como em bancos de dados e tabelas no catálogo federado para o grupo `IAMAllowedPrincipals` não é aceita. + As operações de linguagem de definição de dados (DDL) no catálogo por meio de mecanismos, como Athena, Amazon EMR Spark ou outros, incluindo a definição de configurações do catálogo, não são aceitas. + Operações de DDL em tabelas do RMS usando o Athena não são aceitas. + A criação de visualizações materializadas não é suportada, seja por meio do Athena, do Apache Spark, AWS Glue Data Catalog do ou do consumidor do Amazon Redshift. + O Athena não aceita experiência de vários catálogos. Ele só consegue se conectar a um único catálogo específico por vez. O Athena não consegue acessar nem consultar vários catálogos simultaneamente. + As operações de marcação e ramificação em tabelas do Iceberg por meio do Athena e do Amazon Redshift não são aceitas. + Time Travel em tabelas do RMS não é aceito. + Catálogos de vários níveis com tabelas de data lake não são aceitos. Todos os dados armazenados no Amazon S3 para uso com tabelas de data lake devem residir no padrão AWS Glue Data Catalog e não podem ser organizados em catálogos de vários níveis. + No Amazon Redshift, as unidades de compartilhamento de dados não são adicionadas ao namespace registrado. Clusters e namespaces são sinônimos. Depois de publicar um cluster no AWS Glue Data Catalog, você não pode adicionar novos dados. + O Amazon EMR no EC2 não comporta a união entre tabelas do RMS e Tabelas do Amazon S3. Somente o EMR Sem Servidor aceita esse recurso. + Esquemas e tabelas externos não são aceitos. + As tabelas do RMS são acessíveis somente por meio do endpoint de extensão no Catálogo REST do AWS Glue Iceberg. + As tabelas do Hive não podem ser acessadas por mecanismos de terceiros conectados ao Catálogo REST do AWS Glue Iceberg. + O nível de isolamento read\$1committed em tabelas do RMS por meio do Spark será aceito. + Os nomes dos bancos de dados do Redshift são tratados como sem distinção entre maiúsculas e minúsculas no AWS Glue Data Catalog, restritos a 128 caracteres e podem ser alfanuméricos com traços (-) e sublinhados (\$1). + Os nomes dos catálogos não fazem distinção de maiúsculas e minúsculas, são restritos a 50 caracteres e podem ser alfanuméricos com traços (-) e sublinhados (\$1). + O Amazon Redshift não aceita o uso dos comandos GRANT e REVOKE no estilo SQL do Lake Formation para gerenciar permissões de acesso em tabelas publicadas no AWS Glue Data Catalog. + As políticas de segurança por linha e de mascaramento dinâmico de dados anexadas ao cluster produtor (de origem) do Amazon Redshift não serão aplicadas. Em vez disso, as permissões de acesso definidas no Lake Formation serão aplicadas aos dados compartilhados. + Operações de linguagem de definição de dados (DDL) e linguagem de manipulação de dados (DML) em links de tabela não são aceitas. + Se as palavras-chave reservadas não forem devidamente tratadas com caracteres de escape, ocorrerão falhas ou erros. + A criptografia de dados em cenários de vários catálogos não é aceita. # Limitações da integração do catálogo do S3 Tables O Amazon S3 Tables se integra ao AWS Glue Data Catalog (Catálogo de dados) e registra o catálogo como um local de dados do Lake Formation. Você pode configurar esse registro no console do Lake Formation ou usando o serviço APIs. **nota** Se você tiver uma política baseada em recursos do IAM ou do S3 Tables que restringe os usuários do IAM e as funções do IAM com base nas tags principais, você deve anexar as mesmas tags principais à função do IAM que Lake Formation usa para acessar seus dados do S3 (por exemplo, LakeFormationDataAccessRole) e conceder a essa função as permissões necessárias. Isso é necessário para que a política de controle de acesso baseada em tags funcione corretamente com integração de analytics da funcionalidade Tabelas do S3. As seguintes limitações se aplicam à integração do catálogo de tabelas do S3 com o Data Catalog e o Lake Formation: + AWS Glue e Lake Formation não oferecem suporte a nomes de colunas com letras maiúsculas e minúsculas e convertem todos os nomes de colunas em minúsculas. É necessário verificar se os nomes das colunas da tabela são exclusivos quando convertidos em minúsculas. Use `customer_id` em vez de `customerId`. O uso de nomes de colunas com letras maiúsculas e minúsculas foi aceito somente durante a versão prévia. + A CreateCatalog API não pode criar buckets de tabela no Amazon S3. + A SearchTables API não pode pesquisar tabelas do S3. # Considerações e limitações do compartilhamento de dados de armazenamento de metadados do Hive Com a federação de AWS Glue Data Catalog metadados (federação do catálogo de dados), você pode conectar o catálogo de dados a metastores externos que armazenam metadados para seus dados do Amazon S3 e gerenciar com segurança as permissões de acesso aos dados usando. AWS Lake Formation As seguintes considerações e limitações se aplicam aos bancos de dados federados criados a partir dos bancos de dados do Hive: **Considerações** + **AWS SAM suporte de aplicativos** — Você é responsável pela disponibilidade dos recursos do aplicativo que são AWS SAM implantados (Amazon API Gateway e pela função Lambda). Certifique-se de que a conexão entre o metastore AWS Glue Data Catalog e o Hive esteja funcionando quando os usuários executam consultas. + **Requisito da versão do metastore do Hive**: é possível criar bancos de dados federados somente usando o Apache Hive versão 3 e posterior. + **Requisito de banco de dados mapeado** — Todo banco de dados do Hive deve ser mapeado para um novo banco de dados no Lake Formation. + **Suporte à federação em nível de banco de dados** — Você pode se conectar ao repositório do Hive somente no nível do banco de dados. + **Permissões em bancos de dados federados** — As permissões aplicadas em um banco de dados federado ou tabelas em um banco de dados federado persistem mesmo quando uma tabela de origem ou um banco de dados é excluído. Quando o banco de dados ou tabela de origem são recriados, você não precisa conceder as permissões novamente. Quando uma tabela federada com permissões do Lake Formation é excluída na fonte, as permissões do Lake Formation ainda estão visíveis e você pode revogá-las se necessário. Se um usuário excluir um banco de dados federado, todas as permissões correspondentes serão perdidas. Recriar o mesmo banco de dados com o mesmo nome não recuperará as permissões do Lake Formation. Os usuários precisarão configurar novas permissões novamente. + **IAMAllowedPrincipais permissões de grupo** em bancos de dados federados — Com base no`DataLakeSettings`, Lake Formation pode definir permissões para todos os bancos de dados e tabelas para um grupo virtual chamado`IAMAllowedPrincipal`. O `IAMAllowedPrincipal` se refere a todos os diretores do IAM que têm acesso aos recursos do catálogo de dados por meio das políticas principais e políticas de AWS Glue recursos do IAM. Se essas permissões existirem em um banco de dados ou tabela, todos as entidades principais terão acesso ao banco de dados ou à tabela. No entanto, o Lake Formation não aceita permissões `IAMAllowedPrincipal` em tabelas em bancos de dados federados. Ao criar bancos de dados federados, certifique-se de passar o parâmetro `CreateTableDefaultPermissions` como uma lista vazia. Para obter mais informações, consulte [Alterando as configurações padrão do seu data lake](change-settings.md). + **Unir tabelas em consultas** — Você pode unir tabelas de repositório do Hive com tabelas nativas do catálogo de dados para executar consultas. **Limitações** + **Limitação na sincronização de metadados entre o AWS Glue Data Catalog e o metastore do Hive - Depois de estabelecer a conexão do metastore** do Hive, você precisa criar um banco de dados federado para sincronizar os metadados no metastore do Hive com o. AWS Glue Data Catalog As tabelas no banco de dados federado são sincronizadas em runtime quando os usuários executam consultas. + **Limitação na criação de novas tabelas em um banco de dados federado** — Você não poderá criar novas tabelas em bancos de dados federados. + **Limitação de permissão de dados** — O suporte para permissões nas visualizações de tabela do Repositório do Hive não está disponível. # Limitações do compartilhamento de dados do Amazon Redshift AWS Lake Formation permite que você gerencie dados com segurança em um compartilhamento de dados do Amazon Redshift. O Amazon Redshift é um serviço de armazém de dados totalmente gerenciado em escala de petabytes na nuvem. AWS Ao usar o recurso de compartilhamento de dados, o Amazon Redshift ajuda você a compartilhar dados entre Contas da AWS. Para obter mais informações sobre o compartilhamento de dados do Amazon Redshift, consulte [Visão geral do compartilhamento de dados no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/data_sharing_intro.html). As seguintes observações e restrições aplicam-se a bancos de dados federados criados a partir de unidades de compartilhamento de dados do Amazon Redshift: + **Requisito de banco de dados mapeado** — Toda unidade de compartilhamento de dados do Amazon Redshift deve ser mapeada em um novo banco de dados no Lake Formation. Isso é necessário para manter nomes de tabela exclusivos quando a representação dos objetos da unidade de compartilhamento de dados é nivelada no banco de dados do catálogo de dados. + **Limitação na criação de novas tabelas em um banco de dados federado** — Você não poderá criar novas tabelas em bancos de dados federados. + **Permissões nos bancos de dados federados** — As permissões aplicadas em um banco de dados federado ou tabelas em um banco de dados federado persistem mesmo quando uma tabela de origem ou um banco de dados é excluído. Quando o banco de dados ou a tabela de origem são recriados, você não precisa conceder as permissões novamente. Quando uma tabela federada com permissões do Lake Formation é excluída na fonte, as permissões do Lake Formation ainda estarão visíveis e você poderá revogá-las se necessário. Se um usuário excluir um banco de dados federado, todas as permissões correspondentes serão perdidas. Recriar o mesmo banco de dados com o mesmo nome não recuperará as permissões do Lake Formation. Os usuários precisarão configurar novas permissões novamente. + **IAMAllowedPrincipais permissões de grupo em bancos de dados federados** — Com base no`DataLakeSettings`, Lake Formation pode definir permissões para todos os bancos de dados e tabelas para um grupo virtual chamado`IAMAllowedPrincipal`. O `IAMAllowedPrincipal` se refere a todos os diretores do IAM que têm acesso aos recursos do catálogo de dados por meio das políticas principais e políticas de AWS Glue recursos do IAM. Se essas permissões existirem em um banco de dados ou tabela, todos as entidades principais terão acesso ao banco de dados ou à tabela. No entanto, o Lake Formation não aceita permissões `IAMAllowedPrincipal` em tabelas em bancos de dados federados. Ao criar bancos de dados federados, certifique-se de passar o parâmetro `CreateTableDefaultPermissions` como uma lista vazia. Para obter mais informações, consulte [Alterando as configurações padrão do seu data lake](change-settings.md). + **Filtragem de dados** — No Lake Formation, você pode conceder permissões em uma tabela em um banco de dados federado com filtragem em nível de coluna e em nível de linha. No entanto, você não pode combinar a filtragem em nível de coluna e em nível de linha para restringir o acesso na granularidade em nível de célula em tabelas em bancos de dados federados. + **Identificador de distinção entre maiúsculas e minúsculas** — Os objetos de unidades de compartilhamento de dados do Amazon Redshift gerenciados pelo Lake Formation suportarão nomes de tabelas e nomes de colunas somente em minúsculas. Não ative o identificador de diferenciação de maiúsculas e minúsculas para bancos de dados, tabelas e colunas nas unidades de compartilhamento de dados do Amazon Redshift, caso eles sejam compartilhados e gerenciados usando o Lake Formation. + **Suporte a consultas**: você pode consultar unidades de compartilhamento de dados do Amazon Redshift gerenciadas pelo Lake Formation com o Amazon Redshift. O Athena não aceita consultas a unidades de compartilhamento de dados do Amazon Redshift gerenciadas pelo Lake Formation. Para obter mais informações sobre limitações ao trabalhar com unidades de compartilhamento de dados no Amazon Redshift, consulte [Limitações do compartilhamento de dados](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html#limitations-datashare) no Guia do desenvolvedor de banco de dados do Amazon Redshift. # Limitações da integração com o Centro de Identidade do IAM Com Centro de Identidade do AWS IAM, você pode se conectar a provedores de identidade (IdPs) e gerenciar centralmente o acesso de usuários e grupos em todos os serviços de AWS análise. Você pode configurar AWS Lake Formation como um aplicativo habilitado no IAM Identity Center, e os administradores do data lake podem conceder permissões refinadas a usuários e grupos autorizados sobre recursos. AWS Glue Data Catalog As seguintes limitações se aplicam à integração do Lake Formation com o Centro de Identidade do IAM: + Não é possível atribuir usuários e grupos do Centro de Identidade do IAM como administradores de data lake ou administradores somente leitura no Lake Formation. Usuários e grupos do IAM Identity Center podem consultar recursos criptografados do catálogo de dados se você estiver usando uma função do IAM que AWS Glue possa assumir em seu nome para criptografar e descriptografar o catálogo de dados. AWS as chaves gerenciadas não oferecem suporte à propagação de identidade confiável. + Usuários e grupos do Centro de Identidade do IAM só podem invocar operações de API listadas na política `AWSIAMIdentityCenterAllowListForIdentityContext` fornecida pelo Centro de Identidade do IAM. + O Lake Formation permite que os perfis do IAM de contas externas atuem como perfis operadores em nome dos usuários e grupos do Centro de Identidade do IAM para acessar os recursos do Catálogo de Dados, mas as permissões só podem ser concedidas em recursos do Catálogo de Dados dentro da conta proprietária. Se você tentar conceder permissões a usuários e grupos do Centro de Identidade do IAM em recursos do Catálogo de Dados em uma conta externa, o Lake Formation vai gerar o seguinte erro: “Cross-account grants are not supported for the principal”. + Ao usar o Lake Formation com o Centro de Identidade do IAM, a configuração de atribuição da aplicação é definida como `false` padrão. Se você modificar essa configuração diretamente por meio da [API do Centro de Identidade do IAM](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_PutApplicationAssignmentConfiguration.html), deverá gerenciar todas as atribuições da aplicação manualmente usando a API. O Lake Formation não sincroniza nem gerencia automaticamente as alterações de atribuição feitas fora de seus fluxos de trabalho padrão, o que pode afetar os padrões de acesso e os fluxos de autorização em seu ambiente de data lake. # Considerações e práticas recomendadas de controle de acesso com base em tags do Lake Formation É possível criar, manter e atribuir tags do LF para controlar o acesso a bancos de dados, tabelas e colunas do catálogo de dados. Pense nas seguintes práticas recomendadas ao usar o controle de acesso com base em tags do Lake Formation: + Todas as tags do LF devem ser predefinidas antes de poderem ser atribuídas aos recursos do catálogo de dados ou concedidas às entidades principais. O administrador do data lake pode delegar tarefas de gerenciamento de tags gerando *criadores de tags do LF* com as permissões necessárias do IAM. Os engenheiros e analistas de dados decidem sobre as características e os relacionamentos das tags do LF. Os criadores da tags do LF então criam e mantêm as tags do LF no Lake Formation. + Você pode atribuir várias tags do LF aos recursos do catálogo de dados. Somente um valor para uma chave específica pode ser atribuído a um recurso específico. Por exemplo, você pode atribuir `module=Orders`, `region=West` e `division=Consumer` e assim por diante a um banco de dados, uma tabela ou uma coluna. Você não pode atribuir `module=Orders,Customers`. + Você não pode atribuir tags do LF aos recursos ao criá-los. Você só pode adicionar tags do LF aos recursos existentes. + Você pode conceder expressões de tag do LF, não apenas tags do LF únicas, a uma entidade principal. Uma expressão de tag do LF se parece com a seguinte (em pseudocódigo). ``` module=sales AND division=(consumer OR commercial) ``` Uma entidade principal que recebe essa expressão de tag do LF pode acessar somente os recursos do catálogo de dados (bancos de dados, tabelas e colunas) que receberam `module=sales` *e* `division=consumer` ou `division=commercial`. Se você quiser que a entidade principal possa acessar recursos que tenham `module=sales` *ou* `division=commercial`, não inclua ambos na mesma concessão. Faça duas concessões, uma para `module=sales` e outra para `division=commercial`. A expressão de tag do LF mais simples consiste em apenas uma tag do LF, como `module=sales`. + Uma entidade principal que recebe permissões em uma tag do LF com vários valores pode acessar os recursos do catálogo de dados com qualquer um deles. Por exemplo, se um usuário receber uma tag do LF com chave = `module` e valores = `orders,customers`, o usuário terá acesso aos recursos atribuídos `module=orders` ou `module=customers`. + Você precisa ter permissão `Grant with LF-Tag expressions` para conceder permissões de dados nos recursos do catálogo de dados usando o método LF-TBAC. O administrador do data lake e o criador da tag do LF recebem implicitamente essa permissão. Uma entidade principal que tenha a permissão `Grant with LFTag expressions` pode conceder permissões de dados sobre os recursos usando: + o método de recurso nomeado + o método LF-TBAC, mas usando apenas a mesma expressão de tag do LF Por exemplo, suponha que o administrador do data lake faça a seguinte concessão (em pseudocódigo). ``` GRANT (SELECT ON TABLES) ON TAGS module=customers, region=west,south TO user1 WITH GRANT OPTION ``` Nesse caso, `user1` pode conceder `SELECT` em tabelas a outras entidades principais usando o método LF-TBAC, mas somente com a expressão de tag do LF completa `module=customers, region=west,south`. + Se uma entidade principal receber permissões em um recurso com o método LF-TBAC e o método de recurso nomeado, as permissões que a entidade principal tem sobre o recurso são a união das permissões concedidas pelos dois métodos. + O Lake Formation oferece suporte à concessão de `DESCRIBE` e `ASSOCIATE` em tags do LF em todas as contas e à concessão de permissões nos recursos do catálogo de dados em todas as contas usando o método LF-TBAC. Em ambos os casos, o principal é o ID AWS da conta. **nota** O Lake Formation aceita concessões entre contas para organizações e unidades organizacionais usando o método LF-TBAC. Para usar esse recurso, você precisa atualizar as **Configurações de versão entre contas** para a **Versão 3**. Para obter mais informações, consulte [Compartilhamento de dados entre contas no Lake Formation](cross-account-permissions.md). + Os recursos do catálogo de dados criados em uma conta só podem ser marcados usando tags do LF criadas na mesma conta. As tags do LF criadas em uma conta não podem ser associadas a recursos compartilhados de outra conta. + Usar o controle de acesso baseado em tags do Lake Formation (LF-TBAC) para conceder acesso entre contas aos recursos do Catálogo de Dados requer acréscimos à política de recursos do Catálogo de Dados para sua conta. AWS Para obter mais informações, consulte [Pré-requisitos](cross-account-prereqs.md). + As chaves da tag do LF e os valores da tag do LF não podem exceder 50 caracteres de comprimento. + O número máximo de tags do LF que podem ser atribuídas a um recurso do catálogo de dados é 50. + Os seguintes limites são limites flexíveis: + O número máximo de tags do LF que podem ser criados é 1000. + O número máximo de valores que podem ser definidos para uma tag do LF é 1000. + As chaves e valores das tags são convertidos em letras minúsculas quando são armazenados. + Somente um valor para uma tag do LF pode ser atribuído a um recurso específico. + Se várias tags do LF forem concedidas a uma entidade principal com uma única concessão, a entidade principal poderá acessar somente os recursos do catálogo de dados que tenham todas as tags do LF. + Se uma avaliação da expressão de tag do LF resultar em acesso somente a um subconjunto de colunas da tabela, mas a permissão Lake Formation concedida quando há uma correspondência for uma das permissões que exigiram acesso total à coluna, ou seja, `Alter`, `Drop`, `Insert` ou `Delete`, nenhuma dessas permissões será concedida. Em vez disso, somente `Describe` é concedido. Se a permissão concedida for `All` (`Super`), somente `Select` e `Describe` serão concedidas. + Curingas não são usados com tags do LF. Para atribuir uma tag do LF a todas as colunas de uma tabela, atribua a tag do LF à tabela e todas as colunas na tabela herdam a tag do LF. Para atribuir uma tag do LF a todas as tabelas em um banco de dados, atribua a tag do LF ao banco de dados, e todas as tabelas no banco de dados herdam essa tag do LF. + É possível criar até mil expressões de tag LF em uma conta. + Você pode usar até cinquenta expressões de tag LF para conceder permissões a uma entidade principal nos recursos do Data Catalog. + Quando você concede ou revoga permissões em uma expressão de tag LF em linha, o tamanho da expressão de tag LF não pode exceder 900 bytes. Para conceder permissões em expressões de tag LF maiores, use as expressões de tag LF salvas. Para obter mais informações, consulte [Criar expressões de tag LF](TBAC-creating-tag-expressions.md). + Para adicionar o LF-Tag aos catálogos federados existentes do Redshift que foram criados antes do lançamento geral do suporte ao LF-Tag para catálogos federados, você precisa entrar em contato com a equipe de suporte para obter assistência. AWS # Considerações sobre controle de acesso por atributo, limitações e regiões aceitas As considerações e limitações a seguir se aplicam ao controle de acesso por atributo (ABAC). + O ABAC não comporta a concessão de acesso usando políticas de tag LF. + As permissões que podem ser concedidas não estão disponíveis com o ABAC. + O ABAC não comporta a concessão de permissões aos usuários do Centro de Identidade do IAM. + Quando você usa concessões ABAC em uma tabela no Lake Formation, este não concede permissões `DESCRIBE` ao banco de dados ou catálogo principal. Isso difere dos cenários não ABAC, nos quais o Lake Formation concede permissões `DESCRIBE` implícitas aos recursos principais. + Todas as entidades principais com a chave de tag `AmazonDataZoneProject` são sempre tratadas como aceitas pelo Lake Formation para todos os recursos do Data Catalog. + O ABAC suporta somente atributos de string.