Modelo de controle de acesso de segurança do OneLake (versão prévia)

Este documento fornece um guia detalhado sobre como o modelo de controle de acesso de segurança do OneLake funciona. Ele contém detalhes sobre como as funções são estruturadas, como elas se aplicam aos dados e qual é a integração com outras estruturas no Microsoft Fabric.

Funções de segurança do OneLake

A segurança do OneLake usa um modelo de RBAC (controle de acesso baseado em função) para gerenciar o acesso aos dados no OneLake. Cada função é composta por vários componentes principais.

Tipo: Se a função dá acesso (GRANT) ou remove o acesso (DENY). Há suporte apenas para funções de tipo GRANT.
Permissão: A ação ou as ações específicas que estão sendo concedidas ou negadas.
Âmbito: Os objetos OneLake que têm a permissão. Objetos são tabelas, pastas ou esquemas.
Membros: Qualquer identidade do Microsoft Entra atribuída à função, como usuários, grupos ou identidades não externas. A função é concedida a todos os membros de um grupo do Microsoft Entra.

Ao atribuir um membro a uma função, esse usuário está sujeito às permissões associadas no escopo dessa função. Como a segurança do OneLake usa um modelo de negação por padrão, todos os usuários começam sem acesso aos dados, a menos que sejam concedidos explicitamente por uma função de segurança do OneLake.

Permissões e itens com suporte

As funções de segurança do OneLake dão suporte à seguinte permissão:

Ler: Concede ao usuário a capacidade de ler dados de uma tabela e exibir os metadados de tabela e coluna associados. Em termos SQL, essa permissão é equivalente a VIEW_DEFINITION e SELECT. Para obter mais informações, consulte a segurança de metadados.
ReadWrite: Concede ao usuário a capacidade de ler e gravar dados de uma tabela ou pasta e exibir os metadados de tabela e coluna associados. Em termos SQL, essa permissão é equivalente a ALTER, DROP, UPDATE e INSERT. Para obter mais informações, consulte a permissão ReadWrite.

A segurança do OneLake permite que os usuários definam funções de acesso a dados somente para os itens do Fabric a seguir.

Item de tecido	Situação	Permissões com suporte
Lakehouse	Visualização Pública	Leitura, Leitura/Gravação
Catálogo Espelhado do Azure Databricks	Visualização Pública	Ler

Permissões de segurança e workspace 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 do Fabric dão permissões que se aplicam a todos os itens no workspace. A tabela a seguir descreve as permissões básicas permitidas pelas funções de workspace.

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
Pode editar funções de segurança do OneLake	Sempre* Sim	Sempre* Sim	Não	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.

As funções de workspace gerenciam o acesso a dados do painel de controle, o que significa interações com a criação e o gerenciamento de artefatos e permissões do Fabric. Além disso, as funções de workspace também fornecem níveis de acesso padrão aos itens de dados usando funções padrão de segurança do OneLake. (Observe que as funções padrão se aplicam somente aos Visualizadores, uma vez que o Administrador, o Membro e o Colaborador têm acesso elevado por meio da permissão De gravação) Uma função padrão é uma função de segurança normal do OneLake que é criada automaticamente com cada novo item. Ele fornece aos usuários com determinadas permissões de workspace ou item um nível padrão de acesso aos dados nesse item. Por exemplo, os itens do Lakehouse têm uma função DefaultReader que permite aos usuários com a permissão ReadAll ver dados no Lakehouse. Isso garante que os usuários que acessam um item recém-criado tenham um nível básico de acesso. Todas as funções padrão usam um recurso de virtualização de membro, para que os membros da função sejam qualquer usuário nesse workspace com a permissão necessária. Por exemplo, todos os usuários com permissão ReadAll no Lakehouse. A tabela a seguir mostra quais são as funções padrão padrão. Os itens podem ter funções padrão especializadas que se aplicam somente a esse tipo de item.

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.

Permissões de segurança e item do OneLake

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. Para obter mais informações sobre o compartilhamento de itens, consulte Como funciona o compartilhamento do Lakehouse

Permissão	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 meio da função DefaultReader. 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

*Depende do modo de ponto de extremidade de análise do SQL.

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.

Acesso do mecanismo e do usuário aos dados

O acesso a dados ao OneLake ocorre de duas maneiras:

Por meio de um mecanismo de consulta do Fabric ou
Por meio do acesso do usuário (consultas de mecanismos não Fabric são consideradas acesso do usuário)

A segurança do OneLake garante que os dados sejam sempre mantidos seguros. Como determinados recursos de segurança do OneLake, como segurança em nível de linha e coluna, não são compatíveis com operações de nível de armazenamento, nem todos os tipos de acesso a dados protegidos em nível de linha ou coluna podem ser permitidos. Isso garante que os usuários não possam ver linhas ou colunas às quais não têm permissão. Os mecanismos do Microsoft Fabric estão habilitados para aplicar filtragem de segurança em nível de linha e coluna a consultas de dados. Isso significa que quando um usuário consulta dados em um lakehouse ou outro item com RLS de segurança do OneLake ou CLS nele, os resultados que o usuário vê têm as linhas e colunas ocultas removidas. Para acesso do usuário aos dados no OneLake com RLS ou CLS, a consulta será bloqueada se o usuário que solicita acesso não tiver permissão para ver todas as linhas ou colunas nessa tabela.

A tabela a seguir descreve quais mecanismos do Microsoft Fabric dão suporte à filtragem RLS e CLS.

Motor	Filtragem de RLS/CLS	Status
Lakehouse	Sim	Versão prévia pública
Notebooks Spark	Sim	Versão prévia pública
Ponto de extremidade da Análise de SQL no "modo de identidade do usuário"	Sim	Versão prévia pública
Modelos semânticos usando DirectLake no modo OneLake	Sim	Versão prévia pública
Eventhouse	Não	Planejado
Tabelas externas do data warehouse	Não	Planejado

Detalhes do modelo de controle de acesso de segurança do OneLake

Esta seção fornece detalhes sobre como as funções de segurança do OneLake concedem acesso a escopos específicos, como esse acesso opera e como o acesso é resolvido entre várias funções e tipos de acesso.

Segurança em nível de tabela

Todas as tabelas OneLake são representadas por pastas no lago de dados, mas nem todas as pastas no lago de dados são tabelas do ponto de vista dos mecanismos de consulta e segurança do OneLake no Fabric. Para ser considerada uma tabela válida, as seguintes condições devem ser atendidas:

A pasta existe no diretório Tabelas/diretório de um item.
A pasta contém uma pasta _delta_log com arquivos JSON correspondentes para os metadados da tabela.
A pasta não contém atalhos filho.

Todas as tabelas que não atenderem a esses critérios terão acesso negado se a segurança no nível da tabela estiver configurada nelas.

Segurança de metadados

O acesso de leitura aos dados da segurança do OneLake concede acesso total aos dados e metadados em uma tabela. Para usuários sem acesso a uma tabela, os dados nunca são expostos e geralmente os metadados não são visíveis. Isso também se aplica à segurança no nível da coluna e à capacidade de um usuário de ver ou não uma coluna nessa tabela. No entanto, a segurança do OneLake não garante que os metadados de uma tabela não estarão acessíveis, especificamente nos seguintes casos:

Consultas de Ponto de Extremidade do SQL: o Ponto de Extremidade da Análise de SQL usa o mesmo comportamento de segurança de metadados que o SQL Server. Isso significa que, se um usuário não tiver acesso a uma tabela ou coluna, a mensagem de erro dessa consulta indicará explicitamente os nomes de tabela ou coluna aos quais o usuário não tem acesso.
Modelos semânticos: conceder a um usuário permissão build em um modelo semântico permite que eles acessem para ver os nomes de tabela incluídos no modelo, independentemente de o usuário ter acesso a eles ou não. Além disso, os visuais de relatório que contêm colunas ocultas mostram o nome da coluna na mensagem de erro.

Herança de permissões

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 são Role1 herdadas Role2 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

Segurança em nível de linha

A segurança do OneLake permite que os usuários especifiquem a segurança em nível de linha gravando predicados SQL para limitar quais dados são mostrados a um usuário. O RLS opera mostrando linhas em que o predicado é avaliado como verdadeiro. Para obter mais informações, consulte a segurança em nível de linha.

A segurança em nível de linha avalia os dados da cadeia de caracteres como não diferenciando maiúsculas de minúsculas, usando a seguinte ordenação para classificação e comparações: Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Ao usar a segurança em nível de linha, verifique se as instruções RLS são limpas e fáceis de entender. Use colunas inteiros para classificação e operações maiores ou menores que. Evite equivalências de cadeia de caracteres se você não souber o formato dos dados de entrada, especialmente em relação aos caracteres unicode ou à confidencialidade de acento.

Segurança no nível da coluna

A segurança do OneLake dá suporte à limitação do acesso a colunas removendo (ocultando) o acesso de um usuário a uma coluna. Uma coluna oculta é tratada como sem permissões atribuídas a ela, resultando na política padrão sem acesso. As colunas ocultas não estarão visíveis para os usuários e as consultas em dados que contêm colunas ocultas não retornam dados para essa coluna. Conforme observado na segurança de metadados , há determinado caso em que os metadados de uma coluna ainda podem estar visíveis em algumas mensagens de erro.

A segurança em nível de coluna também segue um comportamento mais estrito no Ponto de Extremidade do SQL operando por meio de uma semântica de negação. Negar em uma coluna no Ponto de Extremidade do SQL garante que todo o acesso à coluna seja bloqueado, mesmo que várias funções se combinem para dar acesso a ela. Como resultado, o CLS no Ponto de Extremidade do SQL opera usando uma interseção entre todas as funções das quais um usuário faz parte em vez do comportamento de união em vigor para todos os outros tipos de permissão. Consulte a seção Avaliando várias funções de segurança do OneLake para obter mais informações sobre como as funções se combinam.

Permissão de Leitura e Escrita

A permissão ReadWrite fornece aos usuários somente leitura a capacidade de executar operações de gravação em itens específicos. A permissão ReadWrite só é aplicável para visualizadores ou usuários com o permissão Leitura em um item. Atribuir acesso ReadWrite a um Administrador, Membro ou Colaborador não tem efeito, pois essas funções já têm essa permissão implicitamente.

O acesso readWrite permite que os usuários executem operações de gravação por meio de notebooks Spark, do gerenciador de arquivos do OneLake ou das APIs do OneLake. Não há suporte para operações de gravação na interface do usuário do Lakehouse para visualizadores.

A permissão ReadWrite opera das seguintes maneiras:

A permissão de Leitura e Escrita inclui todos os privilégios concedidos pela permissão de Leitura.
Usuários com permissões ReadWrite em um objeto podem executar operações de gravação nesse objeto, inclusive. Ou seja, todas as operações também podem ser executadas no próprio objeto.
ReadWrite permite as seguintes ações:
- Criar uma nova pasta ou tabela
- Excluir uma pasta ou tabela
- Renomear uma pasta ou tabela
- Carregar ou editar um arquivo
- Criar um atalho
- Excluir um atalho
- Renomear um atalho
As funções de segurança do OneLake com acesso ReadWrite não podem conter restrições RLS ou CLS.
Como o Fabric só dá suporte a gravações com um único motor em dados, usuários com permissão de leitura e escrita em um objeto só podem gravar nesses dados através do OneLake. No entanto, as operações de leitura serão impostas consistentemente por meio de todos os mecanismos de consulta.

Atalhos

Visão geral de atalhos

A segurança do OneLake se integra com atalhos no OneLake para garantir que os dados dentro e fora do OneLake possam ser facilmente protegidos. Há dois modos de autenticação principais para atalhos:

Atalhos de passagem (SSO): a credencial do usuário de consulta é avaliada em relação ao destino de atalho para determinar quais dados podem ser vistos.
Atalhos delegados: o atalho usa uma credencial fixa para acessar o destino e o usuário de consulta é avaliado em relação à segurança do OneLake antes de verificar o acesso da credencial delegada à origem.

Além disso, as permissões de segurança do OneLake são avaliadas ao criar atalhos no OneLake. Leia sobre permissões de atalho no documento de segurança de atalho.

Segurança do OneLake em atalhos de passagem

A segurança definida em uma pasta OneLake sempre se aplica através de quaisquer atalhos internos para restringir o acesso ao caminho de origem do atalho. 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. Se o item de destino não der suporte à segurança do OneLake, o acesso do usuário será avaliado com base em se ele tem a permissão Fabric ReadAll no item de destino. Os usuários não precisam do Fabric permissão Leitura em um item para acessá-lo por meio de um atalho.

Segurança do OneLake em atalhos delegados

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. O conjunto de segurança em um atalho externo pode ser definido para conceder acesso a todo o atalho ou a qualquer subcaminho dentro do atalho. Outro atalho interno que aponta para um atalho externo ainda requer que o usuário tenha acesso ao atalho externo original.

Ao contrário de outros tipos de acesso na segurança do OneLake, um usuário que acessa um atalho externo requer o Fabric permissão Leitura no item de dados em que reside o atalho externo. Isso é necessário para resolver com segurança a conexão com o sistema externo.

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

Avaliando várias funções de segurança do OneLake

Os usuários podem ser membros de várias funções de segurança diferentes do OneLake, cada uma fornecendo seu próprio acesso aos dados. A combinação dessas funções em conjunto é chamada de "função efetiva" e é o que um usuário verá ao acessar dados no OneLake. As funções são combinadas na segurança do OneLake usando um modelo UNION ou menos restritivo. Isso significa que, se o Role1 fornecer acesso ao TableA e o Role2 fornecer acesso ao TableB, o usuário poderá ver TableA e TableB.

As funções de segurança do OneLake também contêm segurança em nível de linha e coluna, o que limita o acesso às linhas e colunas de uma tabela. Cada política RLS e CLS existe dentro de uma função e limita o acesso a dados para todos os usuários nessa única função. Por exemplo, se Role1 dá acesso à Tabela1, mas tem RLS na Tabela1 e só mostra algumas colunas da Tabela1, a função efetiva para Role1 será os subconjuntos RLS e CLS da Tabela1. Isso pode ser expresso como (R1ols n R1cls n R1rls) em que n é a INTERSECÇÃO de cada componente na função.

Ao lidar com várias funções, RLS e CLS combinam com uma semântica UNION nas respectivas tabelas. CLS é um UNION de conjunto direto das tabelas visíveis em cada função. O RLS é combinado entre predicados usando um operador OR. Por exemplo, WHERE city = 'Redmond' OR city = 'New York'.

Para avaliar várias funções cada uma com RLS ou CLS, cada função é resolvida primeiro com base no acesso dado pela própria função. Isso significa avaliar a INTERSECÇÃO de todos os objetos, linhas e segurança no nível da coluna. Cada função avaliada é então combinada com todas as outras funções das quais um usuário é membro por meio da operação UNION. A saída é a função efetiva para esse usuário. Isso pode ser expresso como:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) )

Por fim, cada atalho em um lakehouse gera um conjunto de funções inferidas que são usadas para propagar as permissões do destino de atalho para o item que está sendo consultado. As funções inferidas operam de maneira semelhante às funções não adiadas, exceto que elas são resolvidas primeiro no destino de atalho antes de serem combinadas com funções no lakehouse de atalho. Isso garante que qualquer herança de permissões no lakehouse de atalho seja interrompida e as funções inferidas sejam avaliadas corretamente. A lógica de combinação completa pode então ser expressa como:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) ) n ( (R1'ols n R1'cls n R1'rls) u (R2'ols n R2'cls n R2'rls)) )

Onde R1' e R2' são as funções inferidas e R1 e R2 são as funções de atalho lakehouse.