Modelo de controle de acesso aos dados do OneLake (versão prévia)

2025-04-17

A segurança do OneLake usa atribuições de função para aplicar permissões a seus membros. Você pode atribuir funções a indivíduos ou a grupos de segurança, grupos do Microsoft 365 e listas de distribuição. Cada membro no grupo de usuários recebe a função atribuída. Se uma pessoa estiver em dois ou mais grupos de segurança ou grupos do Microsoft 365, ela alcançará o nível mais alto de permissão fornecido pelas funções. Se você aninhar grupos de usuários e atribuir uma função a um grupo, todos os usuários contidos terão permissões.

A segurança do OneLake permite que os usuários definam funções de acesso aos dados apenas para Itens do Lakehouse.

A segurança do OneLake restringe o acesso aos dados para usuário Visualizador do workspace ou com acesso de leitura a um lakehouse. Ele não se aplica a administradores, membros ou colaboradores do workspace. Como resultado, a segurança do OneLake dá suporte apenas ao nível de leitura de permissões.

Criar Funções

Você pode definir e gerenciar as funções de segurança do OneLake por meio das configurações de acesso aos dados do lakehouse.

Saiba mais em Introdução às funções de acesso aos dados.

Funções padrão no lakehouse

Quando um usuário cria um novo lakehouse, o OneLake gera funções padrão. Essas funções fornecem aos usuários permissões de acesso do workspace do Fabric aos dados no lakehouse. Você pode excluir ou editar as funções padrão como qualquer outra função.

Definições da função padrão:

Item de tecido	Nome da função	Permissão	Pastas incluídas	Membros atribuídos
Lakehouse	`DefaultReader`	Ler	Todas as pastas em `Tables/` e `Files/`	Todos os usuários com a permissão de Leitura Completa
Lakehouse	`DefaultReadWriter`	Ler	Todas as pastas	Todos os usuários com permissão de gravação

Observação

Para restringir o acesso a usuários específicos ou pastas específicas, modifique a função padrão ou remova-a e crie uma nova função personalizada.

Herança na segurança do OneLake

Para qualquer pasta específica, as permissões de segurança do OneLake sempre herdam toda a hierarquia dos arquivos e subpastas da pasta.

Por exemplo, considere a seguinte hierarquia de um lakehouse no OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Você cria duas funções para este lakehouse. Role1 concede permissão de leitura à folder1 e Role2 concede permissão de leitura à folder2.

Para a hierarquia fornecida, as permissões de segurança do OneLake para Role1 e Role2 herdam da seguinte maneira:

Role1: ler folder1

│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Role2: ler folder2
```
    │   file21.txt
```

Travessia e listagem na segurança do OneLake

A segurança do OneLake fornece navegação automática por itens principais para garantir que os dados sejam fáceis de serem encontrados. A concessão de permissões de leitura de um usuário para subfolder11 concede ao usuário a capacidade de listar e percorrer a folder1 do diretório pai. Essa funcionalidade é semelhante às permissões de pasta do Windows, onde conceder acesso a uma subpasta permite localizar e atravessar os diretórios pai. A lista e a travessia concedidas ao pai não se estendem a outros itens fora dos pais diretos, garantindo que outras pastas fiquem protegidas.

Por exemplo, considere a seguinte hierarquia de um lakehouse no OneLake.

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Para a hierarquia fornecida, as permissões de segurança do OneLake para "Role1" fornece o seguinte acesso. O acesso a file11.txt não é visível, pois não é um pai da subfolder11. Da mesma forma para Role2, file111.txt também não é visível.

Role1: ler subfolder11

Files/
────folder1
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Role2: ler subfolder111

Files/
────folder1
│   │
│   └───subfolder11
|       │
│       └───subfolder111
|            │   file1111.txt

Para atalhos, o comportamento de listagem é ligeiramente diferente. Os atalhos para fontes de dados externas se comportam da mesma forma que as pastas. No entanto, os atalhos para outros locais do OneLake têm comportamento especializado. As permissões de destino do atalho determinam o acesso a um atalho do OneLake. Ao listar atalhos, nenhuma chamada é feita para verificar o acesso de destino. Como resultado, ao listar um diretório, todos os atalhos internos são retornados independentemente do acesso de um usuário ao destino. Quando um usuário tenta abrir o atalho, a verificação de acesso é avaliada e um usuário vê apenas os dados que ele tem as permissões necessárias para ver. Para obter mais informações sobre atalhos, confira a seção de segurança de atalhos.

Considere a hierarquia de pastas a seguir que contém atalhos.

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Role1: ler folder1

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Role2: sem permissões definidas

Files/
│   
└───shortcut2
|
└───shortcut3

Como as permissões de segurança do OneLake são avaliadas com permissões do Fabric

As permissões de item e de workspace permitem que você conceda acesso de "alta granularidade" aos dados no OneLake para o item fornecido. As permissões de segurança do OneLake permitem restringir o acesso aos dados no OneLake apenas a pastas específicas.

Diagrama mostrando a ordem das avaliações de permissões com espaço de trabalho, item e RBAC.

Quando um usuário tenta acessar uma pasta em um lakehouse, a segurança do OneLake primeiro verifica as permissões para o workspace, depois o item do lakehouse e, em seguida, a pasta.

Permissões do workspace e segurança do OneLake

As permissões do workspace são o primeiro limite de segurança para dados no OneLake. Cada workspace representa um único domínio ou área de projeto em que as equipes podem colaborar nos dados. A segurança no workspace é gerenciada por meio de funções de workspace do Fabric. Saiba mais sobre o controle de acesso baseado em função (RBAC) do Fabric: Funções de workspace

As funções de workspace no Fabric concedem as seguintes permissões no OneLake.

Permissão	Administrador	Membro	Colaborador	Visualizador
Exibir arquivos no OneLake	Sempre* Sim	Sempre* Sim	Sempre* Sim	Não por padrão. Use a segurança do OneLake para conceder o acesso.
Gravar arquivos no OneLake	Sempre* Sim	Sempre* Sim	Sempre* Sim	Não

*Como as funções de Administrador, Membro e Colaborador do Workspace concedem automaticamente permissões de Gravação ao OneLake, elas substituem todas as permissões de Leitura de segurança do OneLake.

Função do espaço de trabalho	O OneLake aplica permissões de leitura de RBAC?
Administrador, Colaborador, Membro	Não, a segurança do OneLake ignora quaisquer permissões de leitura RBC do OneLake.
Visualizador	Sim, se as permissões de Leitura de segurança do OneLake estiverem definidas, elas serão aplicadas.

Segurança do OneLake e permissões do Lakehouse

Em um workspace, os itens do Fabric podem ter permissões configuradas separadamente das funções do workspace. As permissões podem ser configuradas por meio do compartilhamento de um item ou do gerenciamento das permissões de um item. A capacidade de um usuário de executar ações em dados no OneLake é determinada pelas permissões a seguir.

Permissões do Lakehouse

Permissão do Lakehouse	Pode exibir arquivos no OneLake?	Pode gravar arquivos no OneLake?	Pode ler dados por meio do endpoint de análise SQL?
Ler	Não por padrão. Use a segurança do OneLake para conceder acesso.	Não	Não
LerTudo	Sim por padrão. Use a segurança do OneLake para restringir acesso.	Não	Não
Escrever	Sim	Sim	Sim
Executar, CompartilharNovamente, VisualizarSaída, VisualizarLogs	N/A - não pode ser concedido por conta própria	N/A - não pode ser concedido por conta própria	N/A - não pode ser concedido por conta própria

Permissões do ponto de extremidade de análise do SQL do lakehouse

Um ponto de extremidade de análise do SQL é um warehouse gerado automaticamente por um Lakehouse no Microsoft Fabric. Um cliente pode fazer a transição da exibição "Lake" do lakehouse (que dá suporte à engenharia de dados e ao Apache Spark) para a exibição "SQL" do mesmo lakehouse. Saiba mais sobre o ponto de extremidade de análise do SQL na documentação do Data Warehouse: ponto de extremidade de análise do SQL.

Permissão do ponto de extremidade de análise do SQL	Os usuários podem exibir arquivos por meio do ponto de extremidade do OneLake?	Os usuários podem gravar arquivos por meio do ponto de extremidade do OneLake?	Os usuários podem ler dados pelo endpoint de análises SQL?
Ler	Não por padrão. Use a segurança do OneLake para conceder acesso.	Não	Não, por padrão, mas pode ser configurado com permissões granulares de SQL.
LerDados	Não por padrão. Use a segurança do OneLake para conceder acesso.	Não	Sim
Escrever	Sim	Sim	Sim

Permissões de modelo semântico do Lakehouse padrão

No Microsoft Fabric, quando o usuário cria um lakehouse, o sistema também provisiona o modelo semântico padrão associado. O modelo semântico padrão tem métricas em cima dos dados do lakehouse. O modelo semântico permite que o Power BI carregue dados nos relatórios.

Permissão de modelo semântico padrão	Pode exibir arquivos no OneLake?	Pode gravar arquivos no OneLake?	Pode exibir o esquema no modelo semântico?	Pode ler dados no modelo semântico?
Ler	Não por padrão. Use a segurança do OneLake para conceder acesso.	Não	Não	Sim por padrão. Pode ser restrito com a Segurança em nível de objeto do Power BI e com a Segurança em nível de linha do Power BI
Construir	Sim por padrão. Use a segurança do OneLake para restringir acesso.	Sim	Sim	Sim
Escrever	Sim	Sim	Sim	Sim
Compartilhar novamente	N/A - não pode ser concedido por conta própria	N/A - não pode ser concedido por conta própria	N/A - não pode ser concedido por conta própria	N/A - não pode ser concedido por conta própria

Quando um usuário compartilha um lakehouse, ele concede a outros usuários ou a um grupo de usuários acesso a um lakehouse sem fornecer acesso ao espaço de trabalho e ao restante de seus itens.

Quando alguém compartilha um lakehouse, também pode conceder as seguintes permissões adicionais:

Permissão ReadData no ponto de extremidade de análise do SQL
Permissão ReadAll no lakehouse
Criar permissão no modelo semântico padrão

Para obter mais informações, consulte Como funciona o compartilhamento do Lakehouse

O ponto de extremidade de análise do SQL é um warehouse. Para obter mais informações sobre seu modelo de permissão, consulte Compartilhar dados do Warehouse e gerenciar permissões

Opção de compartilhamento	Pode exibir arquivos no OneLake?	Pode gravar arquivos no OneLake?	Pode ler dados por meio do endpoint de análise SQL?	Pode exibir e criar modelos semânticos?
Nenhuma permissão adicional selecionada	Não por padrão. Use o RBAC do OneLake para conceder acesso.	Não	Não	Não
Ler todos os dados do ponto de extremidade SQL	Não por padrão. Use o RBAC do OneLake para conceder acesso.	Não	Sim	Não
Ler todo o Apache Spark e se inscrever em eventos	Sim por padrão. Use o RBAC do OneLake para restringir o acesso.	Não	Não	Não
Criar relatórios sobre o conjunto de dados padrão	Sim por padrão. Use o RBAC do OneLake para restringir o acesso.	Não	Não	Sim

Atalhos

Segurança do OneLake em atalhos internos

Para qualquer pasta em um lakehouse, as permissões sempre herdam todos os atalhos internos em que essa pasta é definida como destino.

Quando um usuário acessa os dados por meio de um atalho para outro local do OneLake, a identidade do usuário chamado é usada para autorizar o acesso aos dados no caminho de destino do atalho. Como resultado, esse usuário deve ter permissões da segurança do OneLake no local de destino para ler os dados.

Importante

Ao acessar atalhos por meio de modelos semânticos do Power BI usando o DirectLake em mecanismos SQL ou T-SQL no modo de identidade delegada, a identidade do usuário que realiza a chamada não é transmitida ao destino do atalho. Em vez disso, a identidade do proprietário do item de chamada é passada, delegando o acesso ao usuário de chamada. Para resolver isso, use modelos semânticos do Power BI no DirectLake no modo OneLake ou T-SQL no modo de identidade do usuário.

A definição de permissões de segurança do OneLake para o atalho interno não é permitida e deve ser definida na pasta de destino localizada no item de destino. O item de destino deve ser um tipo de item que dê suporte a funções de segurança do OneLake. Atualmente, apenas o Lakehouse dá suporte a funções de segurança do OneLake.

A tabela a seguir especifica se o cenário de atalho correspondente dá suporte a permissões de segurança do OneLake.

Cenário de atalho interno	As permissões de segurança do OneLake são suportadas?	Comentários
Atalho em um lakehouse apontando para folder2 localizada no mesmo lakehouse.	Com suporte.	Para restringir o acesso aos dados no atalho, defina a segurança do OneLake para folder2.
Atalho em um lakehouse apontando para folder2 localizada em outro lakehouse	Com suporte.	Para restringir o acesso aos dados no atalho, defina a segurança do OneLake para folder2 em outro lakehouse.
Atalho em um lakehouse apontando para uma tabela localizada em um data warehouse	Não há suporte.	O OneLake não dá suporte à definição de permissões de segurança em data warehouses. Em vez disso, o acesso é determinado com base na permissão ReadAll.
Atalho em um lakehouse apontando para uma tabela localizada em um banco de dados KQL	Não há suporte.	O OneLake não dá suporte à definição de permissões de segurança em bancos de dados KQL. Em vez disso, o acesso é determinado com base na permissão ReadAll.

Segurança do OneLake em atalhos externos (ADLS, S3, Dataverse)

O OneLake dá suporte à definição de permissões para atalhos como atalhos do ADLS, do S3 e do Dataverse. Nesse caso, as permissões são aplicadas sobre o modelo de autorização delegado habilitado para esse tipo de atalho.

Suponha que user1 crie um atalho do S3 em um lakehouse apontando para uma pasta em um bucket do AWS S3. Em seguida, o user2 tenta acessar os dados neste atalho.

A conexão do S3 autoriza o acesso para o user1 delegado?	A segurança do OneLake autoriza o acesso para o user2 solicitante?	Resultado: o usuário2 pode acessar dados no Atalho S3?
Sim	Sim	Sim
Não	Não	Não
Não	Sim	Não
Sim	Não	Não

As permissões de segurança do OneLake podem ser definidas para todo o escopo do atalho ou para subpastas selecionadas. As permissões definidas em uma pasta herdam recursivamente todas as subpastas, mesmo que a subpasta esteja dentro do atalho.

Saiba mais sobre os atalhos do S3, do ADLS e do Dataverse em atalhos do OneLake.

Segurança de linha e coluna

As funções de segurança do OneLake permitem segurança em nível de linha (RLS) e segurança em nível de coluna (CLS) em tabelas dentro de um lakehouse. A RLS e a CLS seguem regras de composição específicas para funções simples e múltiplas. Em geral, RLS e CLS são uma interseção dentro de uma função e compõem com uma união entre várias funções.

Observação

A segurança do OneLake está atualmente em uma versão prévia limitada. Para solicitar a participação na versão prévia e acessar esses recursos, preencha o formulário em https://aka.ms/onelakesecuritypreview.

Função única

Ao definir uma função com RLS e CLS, um usuário primeiro escolhe tabelas para permitir acesso. Nessa seleção, restrições como RLS e CLS podem ser definidas em uma ou mais tabelas. A RLS e o CLS atuam como filtros no esquema completo e nos dados atribuídos a uma tabela.

Por exemplo:

UserA é um membro de Role1. Role1 tem a seguinte definição:

Acesso de leitura ao Table1
CLS: A coluna 1 foi removida da Tabela 1.
RLS: Table1 onde Column2 = “US”.

Quando UserA executa uma consulta em Table1, ele vê todas as colunas, exceto a Column1, e apenas as linhas em que a Column2 tem um valor de “US”.

Funções múltiplas

Para RLS e CLS em várias funções, a segurança é combinada por meio de uma união de cada categoria. Cada função produz uma exibição de uma tabela com regras de RLS e de CLS aplicadas e o usuário vê uma união dessas exibições.

A CLS é combinada como uma união simples entre funções. Qualquer restrição coletiva sem restrição resulta em nenhuma restrição a essa tabela.

A RLS é combinada com um OR entre instruções SQL. Assim como na CLS, as regras da RLS, quando unidas com acesso completo à tabela, resultam em todas as linhas sendo visíveis.