Modelo de controle de acesso de segurança OneLake (visualização)

Este documento fornece um guia detalhado sobre como funciona o modelo de controle de acesso de segurança OneLake. 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 controle de acesso baseado em função (RBAC) para gerenciar o acesso aos dados no OneLake. Cada função é composta por vários componentes-chave.

Tipo: Se a função concede acesso (GRANT) ou remove acesso (DENY). Apenas as funções do tipo GRANT são suportadas.
Permissão: A ação ou ações específicas que estão sendo concedidas ou negadas.
Âmbito de aplicação: Os objetos OneLake que têm a permissão. Os objetos são tabelas, pastas ou esquemas.
Membros: Qualquer identidade do Microsoft Entra atribuída à função, como usuários, grupos ou identidades de não usuários. 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 explicitamente concedido por uma função de segurança do OneLake.

Permissões e itens suportados

As funções de segurança do OneLake suportam a seguinte permissão:

Leia-se: 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 utilizador a capacidade de ler e escrever dados a partir de uma tabela ou pasta e visualizar os metadados associados da tabela e coluna. Em termos SQL, esta permissão é equivalente a ALTER, DROP, UPDATE e INSERT. Para mais informações, consulte permissão de ReadWrite.

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

Item de tecido	Situação	Permissões suportadas
Casa do Lago	Pré-visualização Pública	Ler, ReadWrite
Catálogo espelhado do Azure Databricks	Pré-visualização Pública	Leitura

Permissões de segurança e espaço de trabalho do OneLake

As permissões de espaço de trabalho são o primeiro limite de segurança para dados no OneLake. Cada espaço de trabalho representa um único domínio ou área de projeto onde as equipes podem colaborar em dados. Você gere a segurança no espaço de trabalho através de funções de espaço de trabalho Fabric. Saiba mais sobre o controle de acesso baseado em funções do Fabric (RBAC): Funções de Espaço de Trabalho

As funções do espaço de trabalho de malha dão permissões que se aplicam a todos os itens no espaço de trabalho. A tabela a seguir descreve as permissões básicas permitidas pelas funções do espaço de trabalho.

Permissão	Administrador	Membro	Colaborador	Visualizador
Ver ficheiros no OneLake	Sempre* Sim	Sempre* Sim	Sempre* Sim	Não por predefiniçã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 do Espaço de Trabalho, Membro e Colaborador concedem automaticamente permissões de Gravação ao OneLake, elas substituem quaisquer permissões de Leitura de segurança do OneLake.

As funções do espaço de trabalho gerenciam o acesso aos dados do plano de controle, ou seja, as interações com a criação e o gerenciamento de artefatos e permissões do Fabric. Além disso, as funções de espaço de trabalho também fornecem níveis de acesso padrão a itens de dados usando funções padrão de segurança do OneLake. (Observe que as funções padrão só se aplicam a Visualizadores, já que Administrador, Membro e Colaborador têm acesso elevado por meio da permissão Gravação) Uma função padrão é uma função de segurança OneLake normal que é criada automaticamente a cada novo item. Ele oferece aos usuários com determinadas permissões de espaço de trabalho 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 que os usuários com a permissão ReadAll vejam os 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 espaço de trabalho 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 designados
Casa do Lago	`DefaultReader`	Leitura	Todas as pastas em `Tables/` e `Files/`	Todos os utilizadores com permissão ReadAll
Casa do Lago	`DefaultReadWriter`	Leitura	Todas as pastas	Todos os usuários com permissão de gravação

Nota

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.

Segurança do OneLake e permissões de item

Dentro de um espaço de trabalho, os itens do Fabric podem ter permissões configuradas separadamente das funções do espaço de trabalho. Você pode configurar permissões por meio do compartilhamento de um item ou gerenciando as permissões de um item. As permissões a seguir determinam a capacidade de um usuário executar ações em dados no OneLake. Para obter mais informações sobre o compartilhamento de itens, consulte Como funciona o compartilhamento Lakehouse

Permissão	É possível visualizar arquivos no OneLake?	Pode escrever arquivos no OneLake?	Pode-se ler dados através do endpoint de análise SQL?
Leitura	Não por predefinição. Use a segurança do OneLake para conceder acesso.	Não	Não
LeiaTudo	Sim, através da função DefaultReader. Use a segurança do OneLake para restringir o acesso.	Não	Não*
Escrever	Sim	Sim	Sim
Executar, Recompartilhar, VerResultado, VerRegistos	N/A - não pode ser concedido por si só	N/A - não pode ser concedido por si só	N/A - não pode ser concedido por si só

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

Criar funções

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

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

Acesso do motor e do utilizador aos dados

O acesso aos dados do OneLake ocorre de duas maneiras:

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

A segurança do OneLake garante que os dados sejam sempre mantidos seguros. Como determinados recursos de segurança do OneLake, como a segurança em nível de linha e coluna, não são suportados por 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 que não têm permissão para ver. 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 ou CLS de segurança OneLake, 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 abaixo descreve quais mecanismos do Microsoft Fabric oferecem suporte à filtragem RLS e CLS.

Motores	Filtragem RLS/CLS	Situação
Casa do Lago	Sim	Pré-visualização pública
Blocos de anotações Spark	Sim	Pré-visualização pública
Ponto de extremidade do SQL Analytics no "modo de identidade do usuário"	Sim	Pré-visualização pública
Modelos semânticos usando DirectLake no modo OneLake	Sim	Pré-visualização pública
Casa de eventos	Não	Planeado
Tabelas externas do armazém de dados	Não	Planeado

Detalhes do modelo de controle de acesso de segurança 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 em várias funções e tipos de acesso.

Segurança ao nível da tabela

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

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

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 dos metadados

O acesso de leitura aos dados da segurança 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 do 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 do SQL Analytics usa o mesmo comportamento de segurança de metadados do 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 de compilação em um modelo semântico permite que ele acesse 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, 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 uma casa de lago em OneLake:

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

Você cria duas funções para esta casa do lago. Role1 concede permissão de leitura para folder1 e Role2 concede permissão de leitura para folder2.

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

Função1: Ler pasta1

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

Função2: Ler pasta2
```
    │   file21.txt
```

Exploração e listagem na segurança OneLake

A segurança do OneLake proporciona a navegação automática de itens pai para assegurar a fácil descoberta dos dados. Conceder a um utilizador permissões de Leitura para a subpasta11 concede ao utilizador a permissão para listar e navegar pela pasta principal pasta1. Essa funcionalidade é semelhante às permissões de pasta do Windows, em que conceder acesso a uma subpasta proporciona visibilidade e acesso aos diretórios pai. A lista e o acesso concedidos ao pai não se estendem a outros itens fora dos pais, assegurando a segurança de outras pastas.

Por exemplo, considere a seguinte hierarquia de uma casa de lago em 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' fornecem o seguinte acesso. O acesso ao file11.txt não é visível, pois não é o diretório principal da subpasta11. Da mesma forma para Role2, file111.txt também não é visível.

Função1: Ler subpasta 11

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

Função 2: Ler subpasta 111

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

Para atalhos de teclado, o comportamento da 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 só vê os dados que ele tem as permissões necessárias para ver. Para obter mais informações sobre atalhos, consulte a seção de segurança de atalhos .

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

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

Função1: Ler pasta1

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

Função2: Sem permissões definidas

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

Segurança a nível de linha

A segurança do OneLake permite que os usuários especifiquem a segurança em nível de linha escrevendo predicados SQL para limitar quais dados são mostrados a um usuário. A RLS opera mostrando linhas onde 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 o seguinte agrupamento 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, certifique-se de que as instruções RLS estejam limpas e fáceis de entender. Use colunas inteiras para classificação e maior ou menor que operações. Evite equivalências de cadeia de caracteres se você não souber o formato dos dados de entrada, especialmente em relação a caracteres unicode ou sensibilidade de acento.

Segurança ao nível da coluna

A segurança do OneLake suporta a limitação do acesso a colunas removendo (ocultando) o acesso de um usuário a uma coluna. Uma coluna oculta é tratada como não tendo permissões atribuídas a ela, resultando na política padrão de não acesso. As colunas ocultas não serão visíveis para os usuários e as consultas em dados que contenham colunas ocultas não retornarão dados para essa coluna. Como observado na segurança de metadados , há certos casos 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 rigoroso no SQL Endpoint operando por meio de uma semântica de negação. Negar em uma coluna no SQL Endpoint 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 SQL Endpoint 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 Avaliação de 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/Escrita

A permissão de ReadWrite dá aos utilizadores de apenas leitura a capacidade de realizar operações de escrita em itens específicos. A permissão de ReadWrite só se aplica a Visualizadores ou utilizadores com permissão de Ler sobre um item. Atribuir acesso ReadWrite a um Administrador, Membro ou Contribuidor não tem efeito, pois esses papéis já têm essa permissão implicitamente.

O acesso ReadWrite permite aos utilizadores realizar operações de escrita através de cadernos Spark, do explorador de ficheiros OneLake ou das APIs OneLake. Operações de escrita através da interface do Lakehouse para utilizadores visualizadores não são suportadas.

A permissão ReadWrite funciona das seguintes formas:

A permissão ReadWrite inclui todos os privilégios concedidos pela permissão de Ler.
Utilizadores com permissões de ReadWrite num objeto podem realizar operações de escrita nesse objeto, inclusive. Ou seja, quaisquer operações também podem ser realizadas no próprio objeto.
ReadWrite permite as seguintes ações:
- Crie uma nova pasta ou tabela
- Eliminar uma pasta ou tabela
- Renomear uma pasta ou tabela
- Carregar ou editar um ficheiro
- Criar um atalho
- Excluir um atalho
- Renomear um atalho
Os papéis de segurança OneLake com acesso de leitura e escrita não podem conter restrições RLS ou CLS.
Como o Fabric só suporta escritas individuais no motor de dados, os utilizadores com permissão de Leitura/Escrita num objeto só podem escrever nesses dados através de OneLake. No entanto, as operações de Leitura serão aplicadas de forma consistente em todos os motores de consulta.

Atalhos

Visão geral dos atalhos

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

Atalhos de passagem (SSO): a credencial do usuário que está consultando é 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 que 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 OneLake em atalhos de passagem

A segurança definida em uma pasta OneLake sempre flui através de quaisquer atalhos internos para restringir o acesso ao caminho de origem do atalho. Quando um usuário acessa dados por meio de um atalho para outro local do OneLake, a identidade do usuário chamador é usada para autorizar o acesso aos dados no caminho de destino do atalho. Como resultado, esse usuário deve ter permissões de segurança OneLake no local de destino para ler os dados.

Importante

Ao acessar atalhos por meio de modelos semânticos do Power BI usando mecanismos DirectLake sobre SQL ou T-SQL no modo de identidade delegada, a identidade do usuário chamador não é passada para o destino de atalho. Em vez disso, é passada a identidade do proprietário do item que faz a chamada, delegando o acesso ao utilizador que está a chamar. Para resolver isso, use modelos semânticos do Power BI no modo DirectLake sobre 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 ofereça suporte a funções de segurança OneLake. Se o item de destino não oferecer suporte à segurança do OneLake, o acesso do usuário será avaliado com base na permissão ReadAll de malha no item de destino. Os usuários não precisam do Fabric permissão de Ler em um item para acessá-lo por meio de um atalho.

Segurança OneLake em atalhos delegados

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

Suponha que o user1 crie um atalho S3 numa lakehouse apontando para uma pasta num bucket S3 da AWS. Em seguida, user2 está tentando acessar dados neste atalho.

A conexão do S3 autoriza o acesso para o usuário delegado1?	A segurança do OneLake autoriza o acesso para o usuário solicitante2?	Resultado: o usuário2 pode acessar dados no atalho do 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 para todas as subpastas, mesmo que a subpasta esteja dentro do atalho. A segurança definida em um atalho externo pode ter como escopo conceder acesso a todo o atalho ou a qualquer subcaminho dentro do atalho. Outro atalho interno apontando 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 permissão de Ler de malha no item de dados onde o atalho externo reside. Isso é necessário para resolver com segurança a conexão com o sistema externo.

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

Avaliação de 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 juntas é chamada de "função efetiva" e é o que um usuário verá ao acessar dados no OneLake. As funções se combinam na segurança do OneLake usando um modelo UNION ou menos restritivo. Isso significa que, se a Função1 der acesso à Tabela A e a Função2 der acesso à Tabela B, o usuário poderá ver a Tabela A e a Tabela B.

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 de RLS e CLS existe dentro de uma função e limita o acesso aos dados para todos os usuários dentro dessa única função. Por exemplo, se a Função1 der acesso à Tabela1, mas tiver RLS na Tabela1 e mostrar apenas algumas colunas da Tabela1, a função efetiva para a Função1 será os subconjuntos RLS e CLS da Tabela1. Isto pode ser expresso como (R1ols n R1cls n R1rls) onde 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 respetivas tabelas. CLS é um conjunto direto UNION das tabelas visíveis em cada função. A RLS é combinada 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 é primeiro resolvida com base no acesso dado pela própria função. Isso significa avaliar a INTERSEÇÃO de toda a segurança em nível de objeto, linha e 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. Isto pode ser expresso como:

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

Por fim, cada atalho em uma casa de lago 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 forma semelhante às funções não inferidas, exceto que são resolvidas primeiro no local no destino de atalho antes de serem combinadas com funções na casa do lago de atalho. Isso garante que qualquer herança de permissões no atalho lakehouse seja quebrada e que 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 os papéis inferidos e R1 e R2 são os papéis de atalho.