Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A segurança do Direct Lake garante que somente usuários autorizados possam consultar tabelas Delta no OneLake. Você pode gerenciar permissões de acesso a dados por meio de funções de workspace. Colaboradores, membros e administradores do workspace podem ler dados no OneLake. Você também pode conceder acesso aos dados no OneLake por meio de permissões de nível de item e de computação. A terceira opção é aproveitar a segurança do OneLake para impor a segurança baseada em função granular em todos os mecanismos de computação do Fabric. Este artigo explica como alinhar modelos de permissão, escolher SSO (logon único) ou identidades fixas e aproveitar a segurança no nível do objeto (OLS) e a RLS (segurança em nível de linha). Saiba mais na visão geral de segurança do OneLake.
Conceitos-chave e terminologia
Este artigo pressupõe que você esteja familiarizado com estes conceitos:
- O Direct Lake usa expressões M compartilhadas nos metadados de modelo semântico para fazer referência a fontes de dados por meio de funções de acesso a dados do Power Query: AzureStorage.DataLake para Direct Lake no OneLake e Sql.Database para Direct Lake em pontos de extremidade SQL. No entanto, o Direct Lake não usa essas funções para ler as tabelas Delta de origem. Ele lê as tabelas Delta diretamente por meio de APIs do OneLake.
- Para garantir que apenas usuários autorizados consultem os dados, o Direct Lake verifica as permissões de acesso a dados da identidade efetiva. A identidade efetiva depende da configuração de conexão de dados. Por padrão, o Direct Lake usa SSO (ID do Microsoft Entra) e usa a identidade do usuário atual consultando o modelo semântico. Você também pode associar um modelo do Direct Lake a uma conexão de nuvem explícita para fornecer uma identidade fixa.
- Se você conceder permissões de acesso a dados por meio de funções de workspace, somente membros da função Colaboradores (ou superior) poderão ler dados no OneLake. Os Visualizadores de Workspace, no entanto, não têm permissão de leitura no OneLake. Os visualizadores e usuários que não são membros de uma função de workspace podem obter acesso de leitura por meio de uma combinação de permissões de item, permissões de computação ou funções de segurança do OneLake.
- A segurança do OneLake permite que os membros das funções Administrador do Workspace e Membro do Workspace definam segurança granular baseada em funções para usuários na função Visualizador. Especifique as tabelas que um Visualizador ou usuário com permissão de leitura explícita pode acessar e excluir linhas ou colunas específicas. Para saber mais sobre as funções de segurança do OneLake, consulte Segurança de tabela no OneLake, segurança em nível de coluna no OneLake e RLS no OneLake.
Configuração de conexão
Configure conexões de dados para um modelo do Direct Lake da mesma maneira que outros tipos de modelo semântico. Consulte Conectar-se a fontes de dados de nuvem no serviço do Power BI para obter detalhes.
Como o Direct Lake se conecta apenas a fontes de dados do Fabric, a configuração padrão do SSO (Microsoft Entra ID) geralmente funciona, portanto, você não precisa associar modelos semânticos a conexões de dados explícitas. Essa abordagem reduz a complexidade da configuração e reduz a sobrecarga de gerenciamento.
Com o SSO (ID do Microsoft Entra), o Direct Lake verifica se o usuário atual que consulta o modelo semântico tem acesso de leitura aos dados. Somente usuários com acesso de leitura podem consultar os dados. A captura de tela a seguir mostra um modelo do Direct Lake usando a configuração de SSO padrão.
Quando você usa uma conexão de dados explícita com uma identidade fixa em vez de SSO, o Direct Lake não exige que todos os usuários tenham permissão de leitura nos dados subjacentes. Se o SSO do Microsoft Entra permanecer desabilitado na conexão de dados, as permissões da identidade fixa determinarão quais dados o Direct Lake pode acessar.
Observação
Você pode configurar uma conexão de dados para usar o SSO e uma identidade fixa. O Direct Lake verifica as permissões do usuário atual no momento da consulta e usa a identidade fixa para enquadramento e transcodificação no momento da atualização. Para usar uma identidade fixa para consultas e atualizações, verifique se o SSO está desabilitado na configuração de conexão de dados.
Dica
Use o SSO para cenários interativos em que a autorização por usuário é necessária. Utilize uma conexão em nuvem com identidade fixa para cenários de consumo integrado ou de somente leitura onde o acesso ao nível do código-fonte esteja no escopo de uma única conta de serviço. Aplique princípios de privilégio mínimo nos níveis de origem e espaço de trabalho e teste e valide o comportamento para ambos os modos de autenticação antes da implantação em produção.
Requisitos de autenticação
Os modelos do Direct Lake usam a autenticação da ID do Microsoft Entra. Na configuração de conexão de dados, escolha OAuth 2.0, Principal de Serviço ou Identidade do Workspace como o método de autenticação. Outros métodos, como autenticação de chave ou SAS, podem aparecer na interface do usuário de configuração, mas não têm suporte para modelos do Direct Lake.
Requisitos de permissão
Os requisitos de permissão diferem entre Direct Lake em endpoints SQL e Direct Lake em OneLake. Essa diferença existe porque o Direct Lake em endpoints SQL depende do SQL Analytics Endpoint da fonte de dados alvo, enquanto o Direct Lake no OneLake usa as APIs do OneLake para verificações de permissões.
Direct Lake em pontos de extremidade SQL
O Direct Lake nos endpoints SQL verifica as permissões por meio do endpoint de análise SQL para determinar se a identidade efetiva que tenta acessar os dados tem as permissões necessárias. A identidade efetiva não precisa de permissão para ler tabelas Delta diretamente no OneLake. Ele precisa apenas de acesso de leitura ao item do Fabric, como um lakehouse, e de permissão SELECT para uma tabela por meio do respectivo endpoint de análise SQL. O Fabric concede ao modelo semântico as permissões necessárias para ler as tabelas Delta e arquivos Parquet relacionados para carregar dados de colunas na memória. O modelo semântico pode ler regularmente o endpoint de análise SQL para verificar quais dados o usuário que consulta (ou identidade fixa) pode acessar.
Direct Lake no OneLake
O Direct Lake no OneLake não usa um endpoint de análise SQL para verificar permissões. Ele usa segurança OneLake. Quando a segurança OneLake está ativada, o Direct Lake no OneLake usa o usuário atual (ou identidade fixa) para identificar os papéis de segurança do OneLake e aplicar OLS e RLS no item Fabric alvo. Se a segurança do OneLake não estiver ativada, o Direct Lake no OneLake exige que a identidade efetiva tenha permissões Read e ReadAll no item de destino do Fabric para acessar suas tabelas Delta no OneLake. Para mais informações sobre as permissões Ler e Ler Tudo, consulte Compartilhar itens e definir permissões no nível do item.
Observação
Os colaboradores (ou superiores) têm permissões de Read e ReadAll no OneLake. Visualizadores e usuários que não são membros de uma função em um workspace precisam ter as permissões Read e ReadAll ou ser adicionados a um grupo de segurança do OneLake. Para obter mais informações sobre como gerenciar grupos de segurança do OneLake, consulte o modelo de controle de acesso a dados do OneLake.
Usuários do Direct Lake
Os cenários a seguir listam os requisitos mínimos de permissão.
| Scenario | Direct Lake em pontos de extremidade SQL | Direct Lake no OneLake | Comments |
|---|---|---|---|
| Os usuários podem exibir relatórios | - Conceda permissão de leitura para os relatórios e a permissão de leitura para o modelo semântico. - Se o Direct Lake usar SSO, conceda aos usuários pelo menos permissão de leitura para o item Fabric alvo e permissões SELECT para as tabelas. |
- Conceda permissão de leitura para os relatórios e a permissão de leitura para o modelo semântico. - Se o Direct Lake usar SSO, conceda aos usuários pelo menos a permissão Read para o item do Fabric de destino e adicione-os a uma função de segurança do OneLake ou conceda-lhes a permissão ReadAll. |
Os relatórios não precisam pertencer ao mesmo workspace que o modelo semântico. Para obter mais informações, consulte Estratégia para consumidores somente leitura. |
| Os usuários podem criar relatórios | - Conceder permissão de "Build" para o modelo semântico. - Se o Direct Lake usar SSO, conceda aos usuários pelo menos permissão de leitura para o item Fabric alvo e permissões SELECT para as tabelas. |
- Conceder permissão de "Build" para o modelo semântico. - Se o Direct Lake usar SSO, conceda aos usuários pelo menos a permissão Read para o item do Fabric de destino e adicione-os a uma função de segurança do OneLake ou conceda-lhes a permissão ReadAll. |
Os usuários só podem criar relatórios nas tabelas e colunas às quais têm acesso. Essa condição pode ser um subconjunto do conjunto completo de tabelas e colunas no modelo. Para obter mais informações, consulte Estratégia para criadores de conteúdo. |
| Os usuários podem consultar o modelo semântico, mas não têm permissão para consultar o lakehouse ou o ponto de extremidade de análise SQL | - Associe o modelo do Direct Lake a uma conexão de nuvem com uma identidade fixa e deixe o SSO desabilitado. - Conceder à identidade fixa pelo menos permissão de leitura para o item Fabric alvo e permissões SELECT para as tabelas. - Não conceda permissão aos usuários para o item Fabric alvo. |
- Associe o modelo do Direct Lake a uma conexão de nuvem com uma identidade fixa e deixe o SSO desabilitado. - Conceda à identidade fixa pelo menos a permissão Read para o item de destino do Fabric e adicione-a a uma função de segurança do OneLake ou conceda a permissão ReadAll. - Não conceda permissão aos usuários para o item Fabric alvo. |
Adequado somente quando a conexão de nuvem usa uma identidade fixa. |
| Os usuários podem consultar o modelo semântico e o ponto de extremidade de análise do SQL, mas lhes é negada a permissão para consultar o lakehouse | - Conceder permissões de Leitura e ReadData para o item Fabric alvo. | Não aplicável. | Importante: Consultas enviadas ao endpoint de análise SQL contornam as permissões de acesso aos dados que o modelo semântico exige. |
| Gerenciar o modelo semântico, incluindo configurações de atualização | - Requer propriedade semântica do modelo. | - Requer propriedade semântica do modelo. | Para obter mais informações, consulte Propriedade do modelo semântico. |
Importante
Sempre teste permissões antes de liberar seu modelo semântico e relatórios para produção.
Para obter mais informações, consulte Permissões de Modelo Semântico.
Proprietários do Direct Lake
Além da identidade efetiva (usuário atual ou identidade fixa), o Direct Lake exige que o proprietário do modelo semântico tenha acesso de leitura às tabelas de origem para que o Direct Lake possa enquadrar o modelo semântico como parte da atualização dos dados. Não importa quem atualize um modelo do Direct Lake, o Direct Lake verifica a permissão do proprietário para garantir que o modelo tenha permissão para acessar os dados. Os requisitos de permissão de acesso a dados do proprietário são os mesmos para os usuários que consultam o modelo.
Se o proprietário do modelo semântico não tiver as permissões de acesso a dados necessárias, o Direct Lake gerará o seguinte erro durante o enquadramento: We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.
Atalhos para tabelas de origem
Atalhos são objetos do OneLake que você adiciona a um lakehouse do Fabric ou outro item do Fabric que apontam para locais de armazenamento internos ou externos. Em um modelo Direct Lake, tabelas Delta adicionadas por atalhos aparecem como nativas no item Fabric conectado porque os atalhos são transparentes quando você acessa dados pela API OneLake.
Quando você acessa atalhos por meio do Direct Lake em pontos de extremidade SQL, o Direct Lake primeiro valida que a identidade efetiva (usuário atual ou identidade fixa) pode acessar a tabela na fonte de dados do modelo semântico. Para atalhos internos, após essa verificação ser aprovada, o Direct Lake usa a identidade do dono da fonte de dados para ler a tabela Delta através do atalho no item Fabric da tabela. O proprietário da fonte de dados deve ter permissão de acesso no local de destino do OneLake. Para atalhos externos, o proprietário da fonte de dados também precisa da permissão de uso na conexão de nuvem com o sistema externo que hospeda a tabela Delta. Para obter mais informações, consulte atalhos do OneLake.
O Direct Lake (sobre o OneLake) tem requisitos de permissão diferentes porque o Ponto de Extremidade Analítico SQL não está envolvido. Quando um usuário acessa dados por meio de um atalho interno para outro local do OneLake, a identidade efetiva (usuário atual ou identidade fixa) deve ter permissão no local de destino. A identidade efetiva deve ser um Colaborador (ou superior), ter permissões de leitura e leitura total ou estar em um papel de segurança do OneLake que conceda acesso de leitura.
Segurança em nível de objeto (OLS) e RLS (segurança em nível de linha)
Tanto os modelos de segurança OneLake quanto os modelos Direct Lake suportam OLS e RLS. O OLS permite que proprietários de itens e administradores protejam tabelas ou colunas específicas. O RLS pode ser usado para restringir o acesso a dados no nível da linha com base em filtros. Você pode definir OLS e RLS na segurança do OneLake, no modelo Direct Lake ou em ambos os locais.
Importante
O Direct Lake não oferece suporte a OLS/RLS na memória para o endpoint de análise SQL. O Direct Lake em endpoints SQL trata essas restrições de maneira diferente, dependendo do tipo. Se uma consulta acessar uma tabela ou coluna restrita pelo OLS do endpoint de análise SQL ou pela segurança no nível da coluna (CLS), a consulta retornará um erro. Se uma consulta faz referência a uma tabela que aplica RLS ou a uma visualização no endpoint de análise SQL, a consulta volta ao modo DirectQuery. Se o fallback do DirectQuery estiver desativado, consultas que dependem de RLS ou visualizações sobre endpoints SQL falham. Direct Lake no OneLake evita essas limitações. Para detalhes, veja Como as consultas são avaliadas no Direct Lake em SQL.
Direct Lake no OneLake OLS/RLS com OneLake Security OLS/RLS
O Direct Lake no OneLake avalia o acesso a objetos protegidos por OLS/RLS, determinando as funções de segurança do OneLake da identidade efetiva e aplicando as regras de OLS/RLS definidas. Os papéis de segurança do OneLake são tratados da mesma forma que os papéis do Direct Lake. Se a identidade efetiva pertence a múltiplos papéis na segurança do OneLake e do Direct Lake, o Direct Lake primeiro une os papéis de segurança do OneLake e então cruza o resultado com os papéis do Direct Lake.
Esta tabela lista situações comuns de solução de problemas causadas por regras conflitantes de segurança do OneLake e do Direct Lake.
| Scenario | Comments |
|---|---|
| Nenhuma linha retornada devido à filtragem RLS | Se a identidade efetiva não tiver permissões de acesso em nível de linha, as consultas poderão retornar resultados vazios. Esse comportamento é esperado quando os filtros RLS excluem todas as linhas do usuário atual. |
| Não é possível localizar a tabela A coluna não pode ser encontrada Falha ao resolver o nome Não é uma tabela, uma variável ou um nome de função válido |
Esses erros geralmente ocorrem quando permissões de objeto estão ausentes após a aplicação de funções de segurança do OneLake. |
Diferenças de escopo do OLS/RLS
A aplicação de OLS e RLS na segurança do OneLake aplica as regras em todos os motores de computação e garante controle de acesso unificado para os usuários. Isso significa que, independentemente do motor de computação — lakehouse, warehouse, modelo semântico ou outro item — as regras de segurança OneLake controlam o acesso aos dados do usuário. Por outro lado, o OLS/RLS definido em um modelo semântico do Direct Lake só se aplica dentro do escopo desse modelo. Outros mecanismos de computação não aplicam essas regras de segurança do Direct Lake, que podem produzir resultados diferentes quando os usuários acessam os dados por meio de outros caminhos.
Importante
Quando você usa tanto o OLS/RLS de segurança OneLake quanto o OLS/RLS Direct Lake, usuários que têm acesso OneLake ainda podem recuperar e trabalhar com os dados — mesmo que as regras do modelo Direct Lake restrinjam ainda mais os dados — porque as regras em nível de modelo não se estendem além do modelo. Use a segurança do OneLake para controle de acesso abrangente em todos os motores de computação.
Metadados de modelo semântico e OLS do OneLake
Metadados de modelo semântico incluem definições de tabelas, colunas, relações e outros elementos de esquema. Usuários com permissões de compilação ou superior podem exibir os metadados do modelo por meio de XML for Analysis (XMLA) e das APIs REST. Para obter mais informações, consulte Permissões de Modelo Semântico.
Para proteger nomes sensíveis de tabelas e colunas no OneLake com OneLake OLS, lembre-se de que a segurança do OneLake se aplica apenas aos membros da função Visualizador do workspace. O OneLake OLS não impede que membros do papel de Contribuidor (ou superior) do workspace descubram tabelas ou colunas seguras porque eles já têm permissão de Escrita para todos os itens do workspace. Membros da função Visualizador com permissões de build ou superiores em um modelo do Direct Lake podem descobrir informações confidenciais de esquema por meio dos metadados do modelo semântico. Esses visualizadores com privilégios mais altos ainda não têm acesso a dados, mas podem ver que as tabelas e colunas protegidas existem.
Um modelo Direct Lake pode existir no mesmo espaço de trabalho do item de origem ou em um espaço de trabalho separado. Conceda a um visualizador no mesmo build de workspace ( ou superior) acesso a um modelo do Direct Lake por meio de permissões de item. Em um workspace separado, um usuário pode ser um Colaborador (ou superior) ou ter permissões de item de build (ou superior) para acessar os metadados do modelo.
Integração do OLS e do Git do OneLake
A integração do Git permite que os desenvolvedores integrem seus processos de ALM (gerenciamento de ciclo de vida do aplicativo) à plataforma Fabric. O repositório Git preserva a estrutura do espaço de trabalho, incluindo todos os itens suportados. Os desenvolvedores têm visibilidade total dos metadados de todos os seus itens no repositório Git. Os metadados de modelo do Direct Lake permitem que eles vejam que as tabelas ou colunas protegidas existem mesmo que não tenham acesso à fonte de dados de destino em outro workspace. Para obter mais informações, consulte O que é a integração do Git do Microsoft Fabric?
Como as consultas são avaliadas no Direct Lake no SQL
O motivo para desenvolver modelos semânticos do Direct Lake é obter consultas de alto desempenho em grandes volumes de dados no OneLake. Portanto, você deve se esforçar para criar uma solução que maximize as chances de consulta na memória.
As etapas a seguir se aproximam de como as consultas direct lake no SQL são avaliadas (e se elas falham). Os benefícios do modo de armazenamento direct lake só são possíveis quando a quinta etapa é alcançada.
- Se a consulta contiver qualquer tabela ou coluna restrita pelo modelo semântico OLS, um resultado de erro será retornado (os visuais do relatório não serão renderizados).
- Se a consulta contiver qualquer coluna restrita pelo CLS do endpoint de análise do SQL (ou se a tabela for negada), um resultado de erro será retornado (os visuais do relatório falharão ao serem renderizados).
- Se a conexão de nuvem usar SSO (padrão), CLS será determinado pelo nível de acesso do consumidor de relatório.
- Se a conexão de nuvem usar uma identidade fixa, CLS será determinado pelo nível de acesso da identidade fixa.
- Se o modelo semântico usar Direct Lake em endpoints SQL e a consulta contiver qualquer tabela nos endpoints de análise do SQL que imponha RLS ou se uma view for usada, a consulta retornará ao modo DirectQuery.
- Se a conexão de nuvem usar SSO (padrão), o RLS será determinado pelo nível de acesso do consumidor de relatório.
- Se a conexão de nuvem usar uma identidade fixa, o RLS será determinado pelo nível de acesso da identidade fixa.
- Se a consulta exceder os guardrails da capacidade, ela retornará ao modo DirectQuery.
- Caso contrário, a consulta será atendida do cache na memória. Os dados da coluna são carregados na memória quando necessário.
Importante
O Direct Lake no OneLake não oferece suporte a fallback para o modo DirectQuery. Se qualquer tabela no ponto de extremidade de análise do SQL impor RLS ou a consulta exceder os guardrails da capacidade, um resultado de erro será retornado (os visuais de relatório não serão renderizados).
Opções de regra de acesso a dados
Você pode configurar regras de acesso a dados em:
- O modelo semântico.
- O ponto de extremidade de análise do SQL (somente no Direct Lake em pontos de extremidade SQL).
- Segurança do OneLake.
Regras no modelo semântico
Se você precisar aplicar regras de acesso a dados, faça isso na segurança do OneLake para que as regras se apliquem em todos os motores de computação e garantam controle de acesso unificado para os usuários. Use o modelo semântico RLS ou OLS quando os consumidores de relatório não recebem permissão para consultar o lakehouse ou o warehouse e a conexão de nuvem usa uma identidade fixa em vez de SSO. O SSO implica que os usuários finais podem acessar a fonte de dados diretamente e, portanto, ignorar regras de segurança no modelo semântico.
Importante
Permissões de item de modelo semântico podem ser definidas explicitamente por meio de aplicativos do Power BI ou adquiridas implicitamente por meio de funções de workspace.
Vale destacar que as regras de acesso a dados do modelo semântico não são impostas aos usuários que têm permissão de Escrita no modelo semântico. Por outro lado, as regras de acesso a dados se aplicam aos usuários atribuídos à função de workspace Viewer. No entanto, os usuários atribuídos à função de Administrador, Membro ou Colaborador no espaço de trabalho têm implicitamente a permissão Gravação no modelo semântico e, portanto, as regras de acesso a dados não são impostas. Para obter mais informações, consulte Funções em espaços de trabalho.
Regras em várias camadas
Você pode aplicar regras de acesso a dados em todas as camadas. No entanto, essa abordagem envolve complexidade extra e sobrecarga de gerenciamento. Nesse caso, use uma identidade fixa para a conexão na nuvem em vez de SSO.
Comparar opções de regra de acesso a dados
A tabela a seguir compara as configurações de acesso a dados para Direct Lake em endpoints SQL e Direct Lake no OneLake.
| Aplicar regras de acesso a dados | Direct Lake no SQL | Direct Lake no OneLake | Comentário |
|---|---|---|---|
| Somente modelo semântico | Supported | Supported | Use essa opção quando os usuários não tiverem permissões de item para consultar o lakehouse ou o warehouse. Configure a conexão de nuvem para usar uma identidade fixa. Obtenha alto desempenho de consulta a partir do cache em memória. |
| Somente ponto de extremidade de análise SQL | Com suporte (volta para DirectQuery) | Não aplicável | Depende de um item de dados do Fabric (como Lakehouse ou Warehouse) que está usando o modo de identidade delegada. Use essa opção quando os usuários precisarem acessar dados do warehouse ou do modelo semântico e com regras consistentes de acesso a dados. Verifique se o SSO está habilitado para a conexão de nuvem. O desempenho da consulta pode ser lento devido ao fallback do DirectQuery. |
| Somente segurança do OneLake | Não aplicável | Supported | Use essa opção para o controle de acesso unificado em todos os mecanismos de computação do Fabric. A segurança do OneLake impõe OLS e RLS consistentemente para todos os usuários que acessam os dados por meio de qualquer caminho. Obtenha alto desempenho de consulta a partir do cache em memória. |
| Várias camadas (modelo semântico e ponto de extremidade SQL) | Supported | Não aplicável | Essa opção envolve sobrecarga extra de gerenciamento. Configure a conexão de nuvem para usar uma identidade fixa. |
| Várias camadas (modelo semântico e segurança do OneLake) | Não aplicável | Supported | As regras de segurança do OneLake são aplicadas primeiro e, em seguida, regras de modelo semânticas. Considere a consolidação de regras em uma camada para reduzir a complexidade. |
Considerações e limitações
Considere essas limitações de segurança do Direct Lake.
Observação
As funcionalidades e os recursos dos modelos semânticos do Direct Lake e da segurança do OneLake evoluem rapidamente. Verifique periodicamente se há atualizações.
- Atribua aos visualizadores do espaço de trabalho funções de segurança do OneLake que concedam acesso de leitura aos itens de origem do Fabric. Se um item de origem tiver atalhos para outro item Fabric, o usuário também precisa de acesso de leitura ao item Fabric alvo de cada atalho.
- Use uma identidade fixa para isolar os usuários de um item Fabric de origem. Associe o modelo do Direct Lake a uma conexão de nuvem. Mantenha o SSO desabilitado na conexão de nuvem para usar a identidade fixa para atualizações e consultas.
- Modelos semânticos Direct Lake que dependem da segurança Fabric OneLake no item de origem não suportam operações de backup.
- Relacionamentos bidirecionais não são suportados em um modelo Direct Lake se o item Fabric de origem depender do RLS de segurança OneLake.
- A segurança do OneLake não dá suporte a definições dinâmicas ou configurações de função complexas, como a combinação de várias funções OLS e RLS entre tabelas relacionadas.
- Consolide as permissões RLS e OLS de segurança do OneLake em uma função por usuário em vez de atribuir várias funções.
- Se a configuração de segurança do OneLake mudar, como devido a alterações de atalho no item-alvo, atualize o Direct Lake nos modelos OneLake que acessam esse item. Você deve atualizar os modelos manualmente ou usando APIs de atualização.
- Se um Lakehouse possuir a segurança do OneLake:
- O ponto de extremidade de análise SQL é, por padrão, com identidade fixada ao proprietário do Lakehouse. Assim, a segurança do ponto de extremidade de análise SQL do OneLake é a mesma do proprietário (sem limitações). O Direct Lake no SQL permanece usando o Direct Lake, a menos que funções extras de acesso granular do SQL sejam adicionadas.
- O endpoint de análise do SQL pode ser alterado para SSO. Quando isso acontece, as funções de segurança do OneLake são adicionadas como regras de controle de acesso granular do SQL e o usuário é impedido de editá-las diretamente no ponto de extremidade de análise do SQL. Neste ponto, Direct Lake no SQL volta para DirectQuery 100% do tempo.