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.
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. Isso ocorre porque o Direct Lake em endpoints SQL depende do endpoint de Análise SQL da fonte de dados de destino, enquanto o Direct Lake no OneLake usa as APIs do OneLake para verificações de permissão.
Direct Lake em pontos de extremidade SQL
O Direct Lake em pontos de extremidade SQL executa verificações de permissão por meio do ponto de extremidade de análise SQL para determinar se a identidade efetiva que tenta acessar os dados possui as permissões de acesso a dados necessárias. Notavelmente, a identidade efetiva não precisa de permissão para ler tabelas Delta diretamente no OneLake. Basta ter acesso de leitura ao artefato do Fabric, como uma lakehouse, e permissão de SELECT em uma tabela por meio de seu endpoint de análise SQL. Isso ocorre porque o Fabric concede as permissões necessárias ao modelo semântico para ler as tabelas Delta e os arquivos Parquet associados (para carregar dados de coluna na memória). O modelo semântico tem permissão para ler periodicamente o endpoint de análises SQL para verificar quais dados o usuário que faz a consulta (ou identidade fixa) pode acessar.
Direct Lake no OneLake
O Direct Lake no OneLake não usa um ponto de extremidade de análise de SQL para verificações de permissão. Ele usa o OneLake Security. Quando o OneLake Security está habilitado, o Direct Lake no OneLake usa o usuário atual (ou identidade fixa) para resolver funções de Segurança do OneLake e impor OLS e RLS no artefato do Fabric de destino. Se o OneLake Security não estiver habilitado, o Direct Lake no OneLake exigirá que a identidade efetiva tenha permissões de leitura e leitura completa no artefato de destino do Fabric para acessar suas tabelas Delta. Para obter mais informações sobre as permissões Read e ReadAll, consulte a seção Permissões de item no artigo de visão geral de segurança do OneLake.
Observação
Os colaboradores (ou superiores) têm permissões de Read e ReadAll no OneLake. Os visualizadores e usuários que não são membros de uma função de workspace devem receber as permissões de leitura e "ReadAll" ou serem 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 Direct Lake usar SSO, conceda aos usuários pelo menos permissão de leitura para o artefato Fabric de destino 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 permissão Read para o artefato do Fabric de destino, adicione-os a uma função de segurança do OneLake ou conceda a permissão ReadAll a eles. |
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 leitura para o artefato de destino do Fabric e permissão para SELECT para as tabelas. |
- Conceder permissão para Build no modelo semântico. - Se o Direct Lake usar SSO, conceda aos usuários pelo menos permissão Read para o artefato do Fabric de destino e adicione-os a uma função de segurança do OneLake ou conceda a eles permissão ReadAll. |
Os usuários só podem criar relatórios nas tabelas e colunas às quais têm acesso. 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. - Conceda à identidade fixa pelo menos permissão de Leitura para o artefato do Fabric de destino e permissões de SELECT para as tabelas. - Não conceda aos usuários nenhuma permissão para o artefato de destino do Fabric. |
- 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 permissão de leitura para o artefato de destino do Fabric e adicione-a a uma função de segurança do OneLake ou conceda permissão de ReadAll. - Não conceda aos usuários nenhuma permissão para o artefato de destino do Fabric. |
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 | - Conceda permissões Read e ReadData para o artefato Fabric de destino. | Não aplicável. | Importante: as consultas enviadas ao ponto de extremidade de análise do SQL ignorarão as permissões de acesso a dados impostas pelo modelo semântico. |
| 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 também 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 de 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 a outro artefato do Fabric para apontar para locais de armazenamento internos ou externos. Em um modelo do Direct Lake, as tabelas Delta adicionadas por meio de atalhos aparecem como nativas no artefato do Fabric conectado porque os atalhos são transparentes quando você acessa dados por meio da API do 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, depois que essa verificação é concluída com sucesso, o Direct Lake usa a identidade do proprietário da fonte de dados para ler a tabela Delta através do atalho no Artefato 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 teclado.
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)
Os modelos OneLake Security e Direct Lake dão suporte a OLS e RLS. O OLS permite que proprietários e administradores de artefatos 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 no OneLake Security, em um modelo do Direct Lake ou em ambos os locais.
Importante
O Direct Lake não dá suporte ao OLS/RLS do ponto de extremidade da Análise de SQL. Para retornar dados corretos, o Direct Lake nos endpoints SQL reverterá para o modo DirectQuery se um artefato do Fabric usar OLS ou RLS. Se o fallback do DirectQuery estiver desabilitado, as consultas em pontos de extremidade SQL falham quando o OLS/RLS estiver definido no Ponto de Extremidade de Análise SQL. Direct Lake sobre OneLake evita essa limitação.
Direct Lake no OneLake OLS/RLS com o OneLake Security OLS/RLS
O Direct Lake no OneLake avalia o acesso a objetos protegidos por OLS/RLS resolvendo as funções de Segurança do OneLake da identidade efetiva e aplicando as regras OLS/RLS definidas. As funções de Segurança do OneLake são tratadas da mesma forma que as funções do Direct Lake. Se a identidade efetiva pertencer a várias funções em OneLake Security e Direct Lake, o Direct Lake primeiro uniu as funções de Segurança do OneLake e, em seguida, cruza o resultado com as funções do Direct Lake.
Esta tabela lista situações comuns de solução de problemas causadas por regras conflitantes de Segurança do OneLake e 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 as 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 imposição de OLS e RLS no OneLake Security aplica as regras em todos os mecanismos de computação e garante o controle de acesso unificado para os usuários. Isso significa que, independentemente do mecanismo de computação — lakehouse, warehouse, modelo semântico ou outro artefato — as regras de segurança do OneLake controlam o acesso a 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 o OLS/RLS de Segurança do OneLake e o Direct Lake OLS/RLS, os usuários que têm acesso ao OneLake ainda podem recuperar e trabalhar com os dados, mesmo que as regras de modelo do Direct Lake restrinjam ainda mais os dados, porque as regras de nível de modelo não se estendem além do modelo. Use o OneLake Security para controle de acesso abrangente em todos os mecanismos 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 de tabelas e colunas confidenciais no OneLake com o OneLake OLS, lembre-se de que o OneLake Security se aplica apenas aos membros da função de visualizador do workspace. OneLake OLS não impede que membros da função de espaço de trabalho Colaborador (ou superior) descubram tabelas ou colunas protegidas porque eles já têm permissão de gravação para todos os artefatos do espaço de trabalho. 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 workspace que o artefato de origem, ou em um workspace 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 da área de trabalho, incluindo todos os artefatos 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?
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 de workspace funções de segurança do OneLake que concedem acesso de leitura aos artefatos do Fabric de origem. Se um artefato de origem tiver atalhos para outro artefato do Fabric, o usuário também precisará de acesso de leitura ao artefato do Fabric de destino de cada atalho.
- Use uma identidade fixa para isolar os usuários de um artefato de origem da Fabric. 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 do Direct Lake que dependem da segurança do Fabric OneLake no artefato de origem não dão suporte a operações de backup.
- Não há suporte para relações bidirecionais em um modelo do Direct Lake se o artefato de origem do Fabric depender da RLS de segurança do OneLake.
- Durante a visualização pública, a segurança do OneLake dá suporte apenas ao RLS estático em uma única tabela.
- Durante a visualização pública, a segurança do OneLake não dá suporte a definições dinâmicas ou configurações de função complexas, como combinar 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 for alterada, como devido a alterações de atalho no artefato de destino, atualize o Direct Lake em modelos do OneLake que acessam esse artefato. Se o autossíncrono estiver habilitado, o serviço geralmente os atualizará automaticamente. Caso contrário, atualize os modelos manualmente.
- 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.