Integre a segurança do Direct Lake

A segurança Direct Lake garante que apenas usuários autorizados possam consultar tabelas Delta no OneLake. Você pode gerenciar permissões de acesso a dados por meio de funções de espaço de trabalho. Os contribuidores, membros e administradores do espaço de trabalho 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 computação. A terceira opção é aproveitar a segurança do OneLake para impor segurança granular baseada em função em todos os mecanismos de computação Fabric. Este artigo explica como alinhar modelos de permissão, escolher o logon único (SSO) ou identidades fixas e aproveitar a segurança no nível do objeto (OLS) e a segurança em nível de linha (RLS). Saiba mais em 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 do 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 em OneLake e Sql.Database para pontos de extremidade Direct Lake em 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 das APIs do OneLake.
• Para garantir que apenas usuários autorizados consultem os dados, o Direct Lake verifica as permissões de acesso aos dados da identidade efetiva. A identidade efetiva depende da configuração da conexão de dados. Por padrão, o Direct Lake usa SSO (Microsoft Entra ID) e usa a identidade do usuário atual que consulta o modelo semântico. Você também pode vincular um modelo 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 espaço de trabalho, somente os membros da função Colaboradores (ou superior) poderão ler dados no OneLake. Os Visualizadores de Espaço de Trabalho, 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 espaço de trabalho 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 Espaço de Trabalho e Membro do Espaço de Trabalho definam segurança granular baseada em função para os 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 da conexão

Configure conexões de dados para um modelo Direct Lake da mesma forma que outros tipos de modelo semântico. Consulte Conectar-se a fontes de dados na nuvem no serviço do Power BI para obter detalhes.

Como o Direct Lake se conecta apenas a fontes de dados de malha, a configuração padrão de SSO (Microsoft Entra ID) geralmente funciona, portanto, você não precisa vincular 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 (Microsoft Entra ID), 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 Direct Lake usando a configuração 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 Microsoft Entra SSO permanecer desativado na conexão de dados, as permissões da identidade fixa determinarão quais dados o Direct Lake pode acessar.

Requisitos de autenticação

Os modelos Direct Lake usam a autenticação Microsoft Entra ID. Na configuração da conexão de dados, escolha OAuth 2.0, Service Principal ou Workspace Identity 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 são suportados para modelos Direct Lake.

Requisitos de permissão

Os requisitos de permissão diferem entre Direct Lake em pontos de extremidade SQL e Direct Lake em OneLake. Isso ocorre porque o Direct Lake em endpoints SQL depende do SQL Analytics Endpoint 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 nos pontos de extremidade SQL

O Direct Lake nos pontos de extremidade SQL executa verificações de permissão por meio do ponto de extremidade de análises SQL para determinar se a identidade eficaz que tenta acessar os dados tem as permissões de acesso aos dados necessárias. Notavelmente, a identidade efetiva não precisa de permissão para ler tabelas Delta diretamente no OneLake. É suficiente ter acesso de leitura ao artefato Fabric, como um lakehouse, e permissão SELECT em uma tabela por meio do seu endpoint de análise SQL. Isso 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álise SQL para verificar a quais dados o utilizador que consulta (ou uma identidade fixa) pode aceder.

Lago direto em OneLake

O Direct Lake no OneLake não usa um endpoint de análise SQL para verificações de permissão. Ele usa OneLake Security. Quando a Segurança do OneLake está habilitada, o Direct Lake no OneLake usa o usuário atual (ou identidade fixa) para atribuir funções de segurança e impor OLS e RLS no objeto Fabric de destino. Se a Segurança do OneLake não estiver ativada, o Direct Lake no OneLake exige que a identidade efetiva tenha permissões de Leitura e ReadAll no artefacto Fabric de destino para aceder às suas tabelas Delta no OneLake. Para obter mais informações sobre as permissões Ler e ReadAll, consulte a seção Permissões de item no artigo Visão geral de segurança do OneLake.

Usuários diretos do Lago

Os cenários a seguir listam os requisitos mínimos de permissão.

Para obter mais informações, consulte Permissões de modelo semântico.

Proprietários diretos do lago

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 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 aos dados do proprietário são os mesmos que 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

Os atalhos são objetos OneLake que se adicionam a um lakehouse Fabric ou a outro artefato do Fabric que apontam para locais de armazenamento internos ou externos. Em um modelo Direct Lake, as tabelas Delta adicionadas por meio de atalhos aparecem como nativas no artefato de malha conectado porque os atalhos são transparentes quando você acessa dados por meio da API OneLake.

Quando se acede a atalhos através de Direct Lake em pontos finais SQL, o Direct Lake valida primeiro que a identidade efetiva (utilizador atual ou identidade fixa) pode aceder à tabela na fonte de dados do modelo semântico de dados. Para atalhos internos, depois que essa verificação for concluída, o Direct Lake utiliza 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 utilização na conexão à nuvem com o sistema externo que hospeda a tabela Delta. Para obter mais informações, consulte Atalhos do OneLake.

O Direct Lake sobre OneLake tem requisitos de permissão diferentes porque o ponto de extremidade do SQL Analytics 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 ReadAll ou estar numa função de segurança OneLake que conceda acesso de leitura.

Segurança em nível de objeto (OLS) e segurança em nível de linha (RLS)

Os modelos OneLake Security e Direct Lake suportam OLS e RLS. O OLS permite que proprietários e administradores de artefatos protejam tabelas ou colunas específicas. A RLS pode ser usada 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 Direct Lake ou em ambos os locais.

Direct Lake no OneLake OLS/RLS com OneLake Security OLS/RLS

Direct Lake on OneLake avalia o acesso a objetos protegidos por OLS/RLS, resolvendo as funções de segurança da identidade efetiva no OneLake e aplicando as regras OLS/RLS definidas. As funções de Segurança OneLake são tratadas da mesma forma que as funções Direct Lake. Se a identidade efetiva pertence a várias funções no OneLake Security e no Direct Lake, o Direct Lake começa por unir as funções do OneLake Security e depois intersecta o resultado com as funções do Direct Lake.

Esta tabela lista situações comuns de solução de problemas causadas por regras conflitantes do OneLake Security e Direct Lake.

Diferenças de escopo OLS/RLS

A imposição de OLS e RLS no OneLake Security aplica as regras em todos os mecanismos de computação e garante 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 aos dados do usuário. Por outro lado, OLS/RLS definidos dentro de um modelo semântico Direct Lake só se aplicam 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 outros caminhos.

OneLake OLS e metadados do modelo semântico

Os metadados do modelo semântico incluem definições de tabelas, colunas, relações e outros elementos do esquema. Os usuários com permissões de compilação ou superiores podem visualizar os metadados do modelo por meio de XML for Analysis (XMLA) e APIs REST. Para obter mais informações, consulte Permissões de modelo semântico.

Para proteger nomes de tabelas e colunas confidenciais no OneLake usando o OneLake OLS, tenha em mente que a segurança no OneLake se aplica apenas aos membros do espaço de trabalho na função de Visualizador. O OneLake OLS não impede que os membros da função de espaço de trabalho Colaborador (ou superior) descubram tabelas ou colunas seguras porque já têm permissão de Gravação para todos os artefatos do espaço de trabalho. Os membros da função Visualizador com permissões de compilação ou superiores em um modelo Direct Lake podem descobrir informações confidenciais do esquema por meio dos metadados do modelo semântico. Esses visualizadores com privilégios mais altos ainda não têm acesso aos dados, mas podem ver que as tabelas e colunas protegidas existem.

Um modelo Direct Lake pode existir no mesmo espaço de trabalho que o artefato de origem ou em um espaço de trabalho separado. Conceda a um visualizador no mesmo espaço de trabalho build (ou superior) acesso a um modelo Direct Lake através de permissões de itens. Em um espaço de trabalho separado, um usuário pode ser um Colaborador (ou superior) ou ter permissões de item de compilação (ou superiores) para acessar os metadados do modelo.

Integração OneLake OLS e Git

A integração com o Git permite que os desenvolvedores integrem seus processos de gerenciamento do ciclo de vida do aplicativo (ALM) na plataforma Fabric. O repositório Git preserva a estrutura do espaço 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 do modelo Direct Lake permitem que eles vejam que existem tabelas ou colunas protegidas mesmo que não tenham acesso à fonte de dados de destino em outro espaço de trabalho. Para obter mais informações, consulte O que é a integração do Microsoft Fabric Git?

Considerações e limitações

Considere estas limitações de segurança do Direct Lake.

• Atribuir visualizadores do espaço de trabalho funções de segurança OneLake que concedem acesso de leitura aos artefatos de Fabric de origem. Se um artefato de origem tiver atalhos para outro artefato de malha, o usuário também precisará de acesso de leitura ao artefato de malha de destino de cada atalho.
• Use uma identidade fixa para isolar os utilizadores de um artefato de Framework de origem. Vincule o modelo Direct Lake a uma conexão de nuvem. Mantenha o SSO desativado na conexão de nuvem para usar a identidade fixa para atualizações e consultas.
• Os modelos semânticos Direct Lake que dependem da segurança do Fabric OneLake no artefato de origem não suportam operações de backup.
• As relações bidirecionais não são suportadas num modelo Direct Lake se o artefacto Fabric de origem depender da segurança RLS do OneLake.
• Durante a visualização pública, a segurança do OneLake suporta apenas RLS estática sobre uma única tabela.
• Durante a visualização pública, a segurança do OneLake não oferece 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 em tabelas relacionadas.
• Consolide as permissões de segurança do OneLake RLS e OLS 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 nos modelos do OneLake que acessam esse artefato. Se a sincronização automática estiver ativada, o serviço geralmente as atualiza automaticamente. Caso contrário, atualize os modelos manualmente.
• Se uma Lakehouse tiver segurança do OneLake:
  • O endpoint de análises SQL, por padrão, é associado de forma fixa ao proprietário do Lakehouse. Assim, a segurança do endpoint de análises SQL no OneLake é a mesma que a 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 ponto de extremidade da análise SQL pode ser configurado para SSO. Quando isso acontece, as funções de segurança do OneLake são adicionadas como regras de controlo de acesso detalhadas do SQL, e o utilizador é impedido de as editar diretamente no endpoint de análise SQL. Neste ponto, o Direct Lake on SQL retorna ao DirectQuery 100% do tempo.