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á. # 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\_1.Col1\_1\_1.Col1\_1\_1\_1.Col1\_1\_1\_1\_1 + 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 que tenha sido 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.