Como a segurança da OneLake controla o acesso a dados

A segurança do OneLake é um sistema baseado em papéis que determina quem pode acessar dados no OneLake e quais ações pode tomar sobre esses dados. Compreender o modelo de controle de acesso a dados ajuda a conceder aos usuários apenas o acesso que eles precisam, para proteger dados sensíveis enquanto ainda permite que as pessoas certas trabalhem com eles.

Este artigo explica como as funções de segurança do OneLake são estruturadas, como elas se integram às permissões de espaço de trabalho e de itens, como o OneLake aplica e determina o acesso aos seus dados e quais limites você deve ter em mente.

Funções de segurança do OneLake

A segurança do OneLake utiliza um modelo de controle de acesso baseado em papéis (RBAC) para gerenciar o acesso aos dados no OneLake. Na experiência de segurança da OneLake, cada função possui os seguintes componentes:

  • Permissões: As permissões que o papel concede aos dados, como Leitura ou ReadWrite.
  • Tipo: O tipo de papel. A segurança do OneLake suporta apenas funções Grant, que dão aos membros acesso aos dados contidos na função. Não oferece suporte a funções do tipo Deny que removem o acesso.
  • Dados na função: As tabelas, pastas ou esquemas aos quais a função concede acesso. Você também pode definir acesso a dados com segurança em nível de linha e coluna em tabelas.
  • Membros na função: As identidades da Microsoft Entra atribuídas à função, como usuários, grupos ou identidades não usuários. Se você atribuir um grupo do Microsoft Entra, a segurança do OneLake concederá a função a todos os membros do grupo.

A segurança da OneLake utiliza um modelo de negação por padrão, então os usuários começam sem acesso aos dados, a menos que uma função de segurança da OneLake conceda explicitamente acesso. Alguns itens do Fabric começam com papéis padrão que dão aos usuários acesso básico com base nas permissões do seu espaço de trabalho.

Permissões e itens com suporte

As funções de segurança do OneLake oferecem suporte às seguintes permissões:

  • Ler: Concede ao usuário a capacidade de ler dados de uma tabela e exibir os metadados de tabela e coluna associados. Em termos de SQL, essa permissão é equivalente tanto a SELECT quanto a VIEW_DEFINITION. Para mais informações, veja Segurança de Metadados.
  • ReadWrite: Concede ao usuário a capacidade de ler e escrever dados em uma tabela ou pasta e visualizar os metadados associados da tabela e coluna. Em termos SQL, essa permissão é equivalente a ALTER, DROP, UPDATE, e INSERT. Para mais informações, veja Permissão de ReadWrite.

Você pode criar funções de segurança OneLake para os seguintes itens Fabric:

Item de tecido Permissões com suporte
Lakehouse Leitura, Leitura/Gravação
catálogo espelhado do Azure Databricks Ler
Bancos de dados espelhados Ler
Catálogos espelhados Ler

Permissão de Leitura e Escrita

Use a permissão de ReadWrite para dar acesso de gravação a dados específicos de um item para usuários de somente leitura.

ReadWrite se aplica apenas a usuários com a permissão Ler em um item, como usuários com a função de Visualizador no workspace. Atribuir "ReadWrite" a um Administrador, Membro ou Colaborador do workspace não tem efeito, porque essas funções do workspace já têm acesso de gravação.

ReadWrite inclui todos os privilégios concedidos pela permissão de leitura, além de conceder acesso de escrita ao objeto selecionado e seu conteúdo. Por exemplo, a permissão ReadWrite em uma pasta concede acesso de escrita tanto à pasta quanto aos dados dentro dela.

Usuários com permissão de ReadWrite podem realizar as seguintes ações:

  • Crie, exclua ou renomeie uma pasta ou tabela.
  • Faça upload ou edição de um arquivo.
  • Crie, exclua ou renomeie um atalho.

Os usuários podem realizar operações de escrita por meio de notebooks Spark, do explorador de arquivos OneLake ou das APIs OneLake. Como o Fabric oferece suporte apenas a gravações em dados por um único mecanismo, os usuários com permissão ReadWrite só podem gravar nesses dados por meio do OneLake. Todos os motores de consulta continuam a aplicar operações de leitura de forma consistente.

Funções de segurança do OneLake que concedem a permissão ReadWrite não podem conter restrições de segurança em nível de linha (RLS) ou de segurança em nível de coluna (CLS).

Segurança e permissões de espaço de trabalho do OneLake

As funções do espaço de trabalho são o primeiro limite de segurança dos dados no OneLake. Eles gerenciam o plano de controle – criando e gerenciando itens e permissões do Fabric – e aplicam a todos os itens no workspace. Para ver as permissões específicas do OneLake concedidas por cada função de espaço de trabalho, consulte Conceder acesso com funções de espaço de trabalho. Para saber mais sobre funções nos espaços de trabalho, consulte Funções nos espaços de trabalho no Fabric.

Além do acesso ao plano de controle, as funções do workspace também podem fornecer acesso a itens de dados por meio das funções de segurança padrão do OneLake. (As funções padrão se aplicam apenas aos Leitores, porque as funções de Administrador, Membro e Colaborador têm acesso elevado por meio da permissão Gravar.) Uma função padrão é uma função de segurança normal do OneLake que o Fabric cria automaticamente para cada novo item. Ele fornece aos usuários com permissões específicas de área de trabalho ou de 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. Esse acesso padrão garante que os usuários que trabalham com um item recém-criado tenham um nível básico de acesso. Todos os papéis padrão usam um recurso de virtualização de membros, de modo que os membros da função sejam quaisquer usuários naquele 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 as funções padrão. Os itens podem ter funções padrão específicas que se aplicam apenas a esse tipo de item.

Item de tecido Nome da função Permissão concedida Membros atribuídos
Lakehouse DefaultReader Ler Todos os usuários com a permissão de Leitura Completa
catálogo espelhado do Azure Databricks DefaultReader Ler Todos os usuários com permissão de leitura
Catálogo espelhado DefaultReader Ler Todos os usuários com permissão de leitura
Banco de dados espelhado DefaultReader Ler Todos os usuários com a permissão de Leitura Completa

Você pode modificar ou remover o papel padrão de um item do Fabric para alterar o acesso dos usuários daquele grupo de membros.

Acesso do mecanismo e do usuário aos dados

A segurança do OneLake tem como padrão o acesso menos privilegiado. Algumas operações em nível de armazenamento não conseguem aplicar RLS ou CLS, então quando uma consulta não pode ser filtrada com segurança, o OneLake a bloqueia completamente em vez de arriscar expor dados que o usuário não pode ver. Se uma consulta é filtrada ou bloqueada depende do caminho de acesso – um mecanismo de consulta suportado ou acesso direto do usuário.

Para os motores que suportam filtragem por RLS e CLS e os requisitos de cada um, consulte Ler dados protegidos pela segurança do OneLake.

Escopos e fiscalização

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

O OneLake representa todas as tabelas como pastas, mas do ponto de vista dos mecanismos de segurança e consulta do OneLake no Fabric, nem todas as pastas são tabelas. Para ser uma tabela válida, uma pasta deve atender às seguintes condições:

  • A pasta existe no Tables/ diretório de um item. Para itens habilitados para esquema, a pasta também deve estar em uma pasta de esquema válida.
  • A pasta contém uma _delta_log pasta com arquivos JSON correspondentes para os metadados da tabela.
  • A pasta não contém nenhum atalho filho.

Se você configurar RLS ou CLS em uma tabela, o OneLake nega o acesso quando a pasta da tabela não atende a esses critérios. Sem RLS ou CLS, o OneLake trata uma pasta que não atende a esses critérios como uma pasta e aplica segurança em nível de pasta.

Segurança em nível de linha e em nível de coluna

Em uma função, você pode restringir o acesso a linhas e colunas específicas de uma tabela por meio da segurança em nível de linha e de coluna. Para mais informações sobre o que cada controle faz e como o OneLake o aplica, veja Segurança em nível de tabela, coluna e linha no OneLake. Para informações sobre como RLS e CLS se resolvem quando um usuário pertence a múltiplos papéis, veja Avaliar múltiplos papéis de segurança do OneLake.

Segurança de metadados

A permissão de leitura 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. Essa regra também se aplica à segurança em nível de coluna e à capacidade do usuário de ver ou não uma coluna nessa tabela. No entanto, a segurança da OneLake não garante que os metadados de uma tabela não sejam acessíveis. Certas mensagens de erro e experiências podem mostrar nomes de colunas.

Herança e travessia de permissões de pasta

Permissões de pasta afetam uma hierarquia em duas direções:

  • Herança: Permissões concedidas a uma pasta se aplicam para baixo aos seus arquivos e subpastas.
  • Navegação e listagem: Quando os usuários têm permissão em um item filho, a segurança do OneLake permite que eles listem e percorram as pastas pai para que possam descobrir e navegar até os dados que podem acessar. O deslocamento não concede acesso a arquivos ou pastas irmãos.

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

Você cria uma função, Role1, que concede a permissão Ler em subfolder11. Por herança, os membros dessa função podem ler file111.txt e tudo em subfolder111. Os membros podem ver e percorrer subfolder11 para chegar a file11.txt, mas não conseguem ver subfolder11 porque ele é um elemento irmão de Tables, e não conseguem ver Files porque ele é um elemento irmão de folder1.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Você cria outro papel, Role2, que concede permissão de leitura em folder2. Por meio da herança, os membros podem ler file21.txt. Os membros podem atravessar folder2 e Files para chegar até ele, mas não podem ver folder1 nem nenhum de seus filhos.

Files/
│
└───folder2 <-- READ
    │   file21.txt

Para atalhos, o comportamento é um pouco diferente. Atalhos para fontes de dados externas se comportam da mesma forma que pastas. No entanto, atalhos para outros locais do OneLake têm um comportamento específico. As permissões de destino do atalho determinam o acesso a um atalho do OneLake. Ao listar atalhos, o OneLake não faz nenhuma chamada para verificar o acesso alvo. Como resultado, quando você lista um diretório, o OneLake retorna todos os atalhos internos independentemente do seu acesso ao destino. A verificação de acesso é avaliada assim que você tenta abrir o atalho, e então você vê apenas os dados para os quais tem as permissões necessárias.

Atalhos

A segurança da OneLake se integra com atalhos para proteger dados dentro e fora do OneLake. Atalhos usam um de dois modos de autenticação:

  • Passagem: O atalho usa a identidade do usuário que faz a consulta para acessar o alvo. Passthrough é o padrão para atalhos OneLake-para-OneLake.
  • Delegado: O atalho usa uma identidade de conexão ou uma credencial configurada para acessar o destino. Atalhos OneLake-to-OneLake podem usar autenticação delegada, e atalhos para sistemas externos sempre usam autenticação delegada.

Criar um atalho requer permissões tanto no caminho onde o atalho foi criado quanto no caminho de destino. Para os requisitos para criar e acessar cada tipo de atalho, veja OneLake shortcut security.

Segurança do OneLake em atalhos de passagem direta

Quando um usuário acessa dados por meio de um atalho OneLake-to-OneLake do tipo passthrough, OneLake usa a identidade do usuário solicitante para autorizar o acesso ao caminho de destino. O acesso efetivo do usuário é limitado por suas permissões tanto no caminho de atalho quanto no caminho de destino.

Observação

Identidade do mecanismo de consulta e autenticação por atalho são configurações separadas. Um atalho passthrough normalmente usa a identidade do usuário que faz a chamada para acessar o destino. No entanto, modelos semânticos do Power BI usando Direct Lake sobre SQL e endpoints de análise SQL em modo de identidade delegada utilizam a identidade do proprietário do item de consumo ou fonte de dados. Esse comportamento não altera o modo de autenticação configurado do atalho. Para repasse da identidade do usuário de ponta a ponta, use o Direct Lake no OneLake ou configure o endpoint de análise SQL para usar o modo de acesso usando a identidade do usuário.

Você não pode definir permissões de segurança do OneLake diretamente em um atalho OneLake-to-OneLake. As permissões da pasta que contém o atalho são combinadas com as permissões no caminho de destino. Se o item alvo suporta a segurança OneLake, o usuário precisa de acesso por meio de uma função de segurança OneLake. Se o item alvo não suportar segurança OneLake, o usuário precisa da permissão Fabric ReadAll sobre o item alvo. O usuário não precisa de permissão de leitura Fabric no item alvo apenas para acessar seus dados pelo atalho.

Segurança do OneLake em atalhos delegados

Atalhos delegados usam uma identidade de conexão configurada ou uma credencial configurada em vez da identidade do usuário que faz a chamada para acessar o destino. A segurança do OneLake limita o que o usuário que chama pode acessar por meio dessa conexão.

Atalhos delegados do OneLake

Para um atalho delegado do OneLake para o OneLake, o usuário que faz a chamada vê a interseção entre suas permissões de acesso no caminho do atalho e as permissões de acesso da identidade de conexão configurada no caminho de destino. A segurança em nível de coluna (CLS) é suportada em ambos os caminhos. A segurança em nível de linha (RLS) é suportada no caminho de destino, mas você não pode definir RLS no caminho de atalho.

Atalhos externos delegados

Atalhos para sistemas externos, como ADLS, Amazon S3 e Dataverse, usam uma credencial de conexão configurada para acessar a fonte externa. A segurança OneLake é aplicada além do acesso concedido por essa credencial.

Por exemplo, suponha que o usuário1 crie um atalho de lakehouse para uma pasta em um bucket do Amazon S3, e o usuário2 acesse o atalho a partir do lakehouse. O Usuário2 só pode acessar os dados do S3 se a credencial de conexão S3 configurada puder acessar a fonte e a segurança do OneLake autorizar o usuário2 a acessar o caminho de atalho.

Você pode conceder ao OneLake permissões de segurança para o atalho externo inteiro ou para subcaminhos selecionados. As permissões de uma pasta são herdadas recursivamente por todas as suas subpastas, incluindo as pastas dentro do atalho. Um usuário que acessa um atalho externo por outro atalho OneLake ainda deve ser autorizado pela segurança OneLake aplicada ao atalho externo original.

Acessar um atalho externo via Spark ou uma chamada direta de API OneLake também requer permissão de leitura Fabric no item que contém o atalho externo. Essa permissão é necessária para resolver de forma segura a conexão com o sistema externo.

Avalie múltiplos papéis de segurança da OneLake

Um usuário pode pertencer a múltiplos papéis de segurança da OneLake. O OneLake combina o acesso concedido por esses papéis em um papel eficaz, que determina os dados acessados pelo usuário. O OneLake avalia o papel efetivo em etapas.

Resolver o acesso em cada papel

O OneLake primeiro resolve cada função de forma independente. Dentro de um papel, o usuário pode acessar apenas os dados permitidos pelos três componentes de segurança:

  • A segurança em nível de objeto (OLS) determina quais tabelas ou pastas a função pode acessar.
  • A segurança em nível de linha (RLS) limita quais linhas de uma determinada tabela a função pode acessar.
  • A segurança em nível de coluna (CLS) limita as colunas de uma determinada tabela às quais a função pode acessar.

Como os três componentes se aplicam, o OneLake considera a interseção entre eles. Por exemplo, se o Role1 concede acesso à Tabela1 e restringe suas linhas e colunas, o acesso resolvido para o Role1 é:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

O símbolo de interseção (∩) significa que o usuário recebe apenas o acesso permitido por OLS, RLS e CLS nessa função.

Combinar acesso entre funções

Após resolver cada função, a OneLake combina as funções usando um modelo sindical, ou menos restritivo. O símbolo de união (∪) significa que o acesso concedido por qualquer função passa a fazer parte da função efetiva. Se o Papel1 concede acesso à Tabela A e o Papel2 concede acesso à Tabela B, um usuário que pertença a ambos os papéis pode acessar ambas as tabelas.

Para dois papéis, o papel efetivo é:

Effective role = Role1 ∪ Role2

Quando várias funções concedem acesso à mesma tabela, as regras de segurança em nível de linha se combinam com o operador OR. Por exemplo, predicados que permitem city = 'Redmond' e city = 'New York' são combinados como city = 'Redmond' OR city = 'New York'.

Regras de segurança em nível de coluna também se combinam como uma união, exceto no endpoint de análise SQL. No endpoint de análise SQL, o CLS usa uma semântica de negação mais rigorosa. Se qualquer função esconder uma coluna, o endpoint bloqueia o acesso a essa coluna. Como resultado, o endpoint faz a interseção das listas de permissões do CLS em todas as funções do usuário, em vez de combiná-las em uma união.

Importante

Mantenha na mesma função as regras de RLS e CLS que precisam ser aplicadas em conjunto. O OneLake não suporta uma combinação de papéis em que dois papéis permitam um conjunto diferente de colunas para uma tabela e qualquer um dos papéis também aplica RLS a essa tabela. Por exemplo, um usuário não pode pertencer ao Role1, que permite colunas c1 e c2 e um subconjunto de linhas, e ao Role2, que permite as colunas c2 e c3.

Combinar atalho e acesso ao alvo

Para um atalho, o OneLake avalia as funções na localização do atalho e no destino do atalho separadamente. As funções de destino tornam-se funções inferidas no local do atalho. O OneLake então cruza o acesso combinado das funções de atalho com o acesso combinado das funções de destino inferidas. Essa etapa impede que o acesso herdado no local de atalho sobreponha as restrições ao alvo.

Para duas funções de atalho e duas funções de destino inferidas, o acesso efetivo é:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

Nesta expressão, ShortcutRole1 e ShortcutRole2 são funções na localização do atalho. InferredRole1 e InferredRole2 são os papéis correspondentes inferidos a partir do alvo de atalho. Cada função é resolvida a partir de seus componentes OLS, RLS e CLS antes que a OneLake combine as funções.

Limitações de segurança do OneLake

  • Se você atribuir uma função de segurança do OneLake a um usuário convidado B2B, deverá definir as configurações de colaboração externa para B2B na ID externa do Microsoft Entra. Defina a configuração de acesso de usuário convidado para que usuários convidados tenham o mesmo acesso que membros (mais inclusivo).

  • Se você adicionar uma lista de distribuição a uma função na segurança do OneLake, o ponto de extremidade de análise SQL não consegue resolver os membros da lista para aplicar o controle de acesso. Como resultado, os usuários parecem não ser membros da função quando acessam o endpoint de análise SQL. O Direct Lake em modelos semânticos SQL também está sujeito a essa limitação.

  • Notebooks Spark exigem que o ambiente seja 3.5 ou superior e que uses o runtime do Fabric 1.3.

  • Lakehouses sem esquema não oferecem suporte à visualização prévia dos dados para tabelas protegidas por RLS e CLS. Use casas de lago habilitadas para esquema com segurança OneLake.

  • A segurança do OneLake não funciona com Azure Data Share ou Purview Data Share. Para obter mais informações, consulte Azure Data Share.

  • A tabela a seguir lista as limitações dos papéis de segurança da OneLake.

    Cenário Limite
    Número máximo de funções de segurança do OneLake por Item do Fabric 250 funções por item (ver nota)
    Número máximo de membros por função de segurança do OneLake 500 usuários ou grupos de usuários por função
    Número máximo de permissões por função de segurança do OneLake 500 permissões por função

    Observação

    Você pode solicitar um aumento de funções por item para 1.000. Para solicitar um aumento, entre em contato com Azure Support.

Latências

As alterações nas definições de função levam cerca de 5 minutos para serem aplicadas.

As alterações em um grupo de usuários em uma função de segurança do OneLake levam cerca de uma hora para o OneLake aplicar as permissões da função no grupo de usuários atualizado. Alguns mecanismos do Fabric têm sua própria camada de cache, portanto, pode exigir uma hora extra para atualizar o acesso em todos os sistemas.

Conteúdo relacionado

  • Last updated on