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

A segurança do OneLake é um sistema baseado em papéis que determina quem pode aceder aos dados no OneLake e que ações podem tomar com base nesses dados. Compreender o modelo de controlo de acesso a dados ajuda-o a conceder aos utilizadores apenas o acesso de que precisam, para que possa proteger dados sensíveis enquanto permite que as pessoas certas trabalhem com eles.

Este artigo explica como os papéis de segurança da OneLake estão estruturados, como se integram com permissões de espaço de trabalho e itens, como o OneLake aplica e resolve o acesso aos seus dados, e os limites a ter em conta.

Funções de segurança do OneLake

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

  • Permissões: As permissões que o papel concede aos dados, como Ler ou ReadWrite.
  • Tipo: O tipo de papel. A segurança da OneLake suporta apenas funções Grant, que dão aos membros acesso aos dados da função. Não suporta funções de Negação que removem acesso.
  • Dados na função: As tabelas, pastas ou esquemas a que a função concede acesso. Também pode definir o acesso a dados com segurança ao nível das linhas e colunas nas tabelas.
  • Membros em função: As identidades da Microsoft Entra atribuídas à função, como utilizadores, grupos ou identidades não-utilizadoras. Se atribuir um grupo Microsoft Entra, a segurança da OneLake atribui o papel a todos os membros do grupo.

A segurança do OneLake utiliza um modelo de negação por predefinição, pelo que os utilizadores não têm acesso aos dados à partida, a menos que uma função de segurança do OneLake conceda esse acesso explicitamente. Alguns itens do Fabric começam com papéis predefinidos que dão aos utilizadores acesso básico com base nas permissões do seu espaço de trabalho.

Permissões e itens suportados

Os papéis de segurança OneLake suportam as seguintes permissões:

  • Leia-se: Concede ao utilizador a capacidade de ler dados de uma tabela e visualizar os metadados da tabela e das colunas associados. Em termos de SQL, esta permissão é equivalente a SELECT e a VIEW_DEFINITION. Para mais informações, consulte Segurança de Metadados.
  • ReadWrite: Concede ao utilizador a capacidade de ler e escrever dados numa 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.

Pode criar funções de segurança OneLake para os seguintes itens Fabric:

Item de tecido Permissões suportadas
Casa do Lago Ler, Leitura e Escrita
Catálogo espelhado do Azure Databricks Leitura
Bancos de dados espelhados Leitura
Catálogos em espelho Leitura

Permissão de Leitura/Escrita

Utilize a permissão ReadWrite para conceder aos utilizadores com acesso só de leitura acesso de escrita a dados específicos num item.

ReadWrite aplica-se apenas a utilizadores com permissão de leitura num item, como utilizadores com a função de Visualizador no espaço de trabalho. Atribuir a permissão ReadWrite a um Administrador, Membro ou Contribuidor de uma área de trabalho não tem qualquer efeito, porque estas funções da área de trabalho já têm permissões de escrita.

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

Os utilizadores com permissão de ReadWrite podem realizar as seguintes ações:

  • Crie, apague ou renomeie uma pasta ou tabela.
  • Carregar ou editar um ficheiro.
  • Criar, apagar ou renomear um atalho.

Os utilizadores podem realizar operações de escrita através de cadernos Spark, do explorador de ficheiros OneLake ou das APIs OneLake. Como o Fabric suporta apenas escritas de dados por um único motor, os utilizadores com permissão de ReadWrite só podem escrever nesses dados através do OneLake. Todos os motores de consulta continuam a impor operações de leitura de forma consistente.

As funções de segurança do OneLake que concedem permissão de leitura e escrita não podem conter restrições de segurança ao nível da linha (RLS) nem ao nível da coluna (CLS).

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

As funções da área de trabalho são o primeiro limite de segurança dos dados no OneLake. Gerem o plano de controlo — criando e gerindo itens e permissões no Fabric — e aplicam-se a todos os itens do espaço de trabalho. Para conhecer as permissões específicas do OneLake concedidas por cada função do espaço de trabalho, veja Conceder acesso com funções do espaço de trabalho. Para saber mais sobre funções em espaços de trabalho, consulte Funções em espaços de trabalho no Fabric.

Para além do acesso ao plano de controlo, as funções do espaço de trabalho também podem fornecer acesso a itens de dados através das funções de segurança predefinidas do OneLake. (As funções predefinidas só se aplicam aos Visualizadores, porque as funções de Administrador, Membro e Contribuidor têm acesso elevado através da permissão Escrever.) Uma função predefinida é uma função de segurança normal do OneLake que o Fabric cria automaticamente com 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 aos utilizadores com a permissão ReadAll ver os dados no lakehouse. Este acesso por defeito garante que os utilizadores que trabalham com um item recém-criado tenham um nível básico de acesso. Todas as funções predefinidas utilizam um recurso de virtualização de membros, o que significa que os membros da função são todos os utilizadores nesse espaço de trabalho com a permissão necessária. Por exemplo, todos os utilizadores com a permissão ReadAll no lakehouse.

A tabela seguinte mostra as funções predefinidas padrão. Os itens podem ter papéis predefinidos especializados que se aplicam apenas a esse tipo de item.

Item de tecido Nome da função Permissão concedida Membros designados
Casa do Lago DefaultReader Leitura Todos os utilizadores com permissão ReadAll
Catálogo espelhado do Azure Databricks DefaultReader Leitura Todos os utilizadores com permissão de leitura
Catálogo espelhado DefaultReader Leitura Todos os utilizadores com permissão de leitura
Banco de dados espelhado DefaultReader Leitura Todos os utilizadores com permissão ReadAll

Pode modificar ou remover o papel padrão de um item do Fabric para alterar o acesso dos utilizadores desse grupo de membros.

Acesso do mecanismo e do utilizador aos dados

A segurança do OneLake adota por predefinição o acesso com o menor nível de privilégios. Algumas operações a nível de armazenamento não conseguem aplicar RLS ou CLS, por isso, quando uma consulta não pode ser filtrada com segurança, o OneLake bloqueia-a completamente em vez de arriscar expor dados que o utilizador não pode ver. Se uma consulta é filtrada ou bloqueada depende do caminho de acesso – um motor de consulta suportado ou acesso direto do utilizador.

Para os motores que suportam o filtro RLS e CLS e os requisitos de cada um, veja Ler dados protegidos com segurança OneLake.

Âmbito e aplicação da lei

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

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

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

Se configurar RLS ou CLS numa tabela, o OneLake nega o acesso quando a pasta da tabela não cumpre estes critérios. Sem RLS ou CLS, o OneLake trata uma pasta que não cumpre estes critérios como uma pasta e aplica segurança ao nível da pasta.

Segurança ao nível da linha e ao nível da coluna

Dentro de uma função, pode restringir o acesso a linhas e colunas específicas de uma tabela usando segurança ao nível das linhas e a nível das colunas. Para mais informações sobre o que cada controlo faz e como o OneLake o aplica, consulte Segurança ao nível de tabelas, colunas e linhas no OneLake. Para informações sobre como o RLS e o CLS se resolvem quando um utilizador pertence a múltiplos papéis, consulte Avaliar múltiplos papéis de segurança do OneLake.

Segurança dos metadados

A permissão de leitura da OneLake Security concede acesso total aos dados e metadados numa tabela. Para utilizadores sem acesso a uma tabela, os dados nunca são expostos. Esta regra aplica-se também à segurança ao nível das colunas e à capacidade do utilizador 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 de permissões de pasta e percurso

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

  • Herança: As permissões concedidas a uma pasta aplicam-se para baixo aos seus ficheiros e subpastas.
  • Percorrer e listar: Quando os utilizadores têm permissão sobre um item filho, a segurança do OneLake permite-lhes listar e percorrer as pastas principais, para que possam descobrir e navegar até aos dados a que podem aceder. A travessia não concede acesso a ficheiros ou pastas irmãs.

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

Cria uma função, Role1, que concede a permissão de leitura para 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 está ao mesmo nível de Tables e não conseguem ver Files porque está ao mesmo nível de folder1.

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

Cria outra função, Role2, que concede a permissão Read sobre folder2. Através da herança, os membros podem ler file21.txt. Os membros podem percorrer folder2 e Files para lá chegar, mas não podem ver folder1 nem nenhum dos seus descendentes.

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

Para atalhos, o comportamento é ligeiramente diferente. Os atalhos para fontes de dados externas comportam-se da mesma forma que as pastas. No entanto, os 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 qualquer chamada para verificar o acesso alvo. Como resultado, quando lista um diretório, o OneLake devolve todos os atalhos internos independentemente do seu acesso ao destino. A verificação de acesso avalia assim que tenta abrir o atalho, e depois vê apenas os dados para os quais tem as permissões necessárias.

Atalhos

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

  • Passagem: O atalho usa a identidade do utilizador que faz a consulta para aceder ao destino. Passthrough é o padrão para atalhos OneLake-to-OneLake.
  • Delegado: O atalho utiliza uma identidade de ligação ou credencial configurada para aceder ao destino. Os atalhos OneLake-to-OneLake podem usar autenticação delegada, e os atalhos para sistemas externos usam sempre autenticação delegada.

Criar um atalho requer permissões tanto para o caminho onde o atalho foi criado como para o caminho de destino. Para os requisitos para criar e aceder a cada tipo de atalho, consulte a segurança de atalhos OneLake.

Segurança OneLake em atalhos de passagem direta

Quando um utilizador acede a dados através de um atalho passthrough OneLake-to-OneLake, o OneLake usa a identidade do utilizador que chama para autorizar o acesso ao caminho de destino. O acesso efetivo do utilizador é limitado pelas suas permissões tanto no caminho de atalho como no caminho de destino.

Nota

A identidade do motor de consultas e a autenticação por atalho são definições separadas. Um atalho passthrough utiliza normalmente a identidade do utilizador que efetua a chamada para aceder ao destino. No entanto, os modelos semânticos do Power BI que utilizam o Direct Lake em SQL e os pontos finais de análise SQL no modo de identidade delegada usam a identidade do proprietário do item consumidor ou da origem de dados. Este comportamento não altera o modo de autenticação configurado pelo atalho. Para a propagação da identidade do utilizador de ponta a ponta, utilize o Direct Lake no OneLake ou configure o ponto final de análise SQL para utilizar o modo de acesso com a identidade do utilizador.

Não pode definir permissões de segurança OneLake diretamente num atalho OneLake-to-OneLake. As permissões na pasta que contém o atalho combinam-se com as permissões no caminho de destino. Se o item alvo suporta segurança OneLake, o utilizador precisa de acesso através de um papel de segurança OneLake. Se o item alvo não suportar segurança OneLake, o utilizador precisa da permissão Fabric ReadAll sobre o item alvo. O utilizador não precisa de permissão Fabric Read no item alvo apenas para aceder aos seus dados através do atalho.

Segurança OneLake em atalhos delegados

Os atalhos delegados usam uma identidade de ligação ou credencial configurada em vez da identidade do utilizador que chama para aceder ao alvo. A segurança do OneLake limita o que o utilizador que chama pode aceder através dessa ligação.

Atalhos delegados do OneLake

Para um atalho delegado OneLake-to-OneLake, o utilizador que chama vê a interseção do seu acesso no caminho de atalho e o acesso da identidade de ligação configurada no caminho de destino. A segurança ao nível das colunas (CLS) é suportada em ambos os percursos. A segurança ao nível da linha (RLS) é suportada no caminho de destino, mas não é possível definir RLS no caminho do atalho.

Atalhos externos delegados

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

Por exemplo, suponha que o user1 cria um atalho de lakehouse para uma pasta num bucket do Amazon S3, e o user2 acede ao atalho a partir do lakehouse. O utilizador 2 só pode aceder aos dados S3 se a credencial de ligação S3 configurada conseguir aceder à origem e a segurança OneLake autorizar o utilizador 2 a aceder ao caminho de atalho.

Pode conceder ao OneLake acesso de segurança a todo o atalho externo ou a subcaminhos selecionados. As permissões numa pasta herdam recursivamente para todas as suas subpastas, incluindo as pastas dentro do atalho. Um utilizador que acede a um atalho externo através de outro atalho OneLake deve ainda ser autorizado pela segurança OneLake aplicada ao atalho externo original.

Aceder a um atalho externo através do Spark ou de uma chamada direta à API OneLake também requer permissão de leitura Fabric no item que contém o atalho externo. Esta permissão é necessária para resolver de forma segura a ligação ao sistema externo.

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

Um utilizador pode pertencer a múltiplas funções de segurança da OneLake. O OneLake combina o acesso concedido por esses papéis num papel eficaz, que determina os dados a que o utilizador pode aceder. O OneLake avalia a função efetiva por etapas.

Resolver o acesso dentro de cada função

O OneLake resolve primeiro cada função de forma independente. Dentro de um papel, um utilizador pode aceder apenas aos dados permitidos pelos três componentes de segurança:

  • A segurança ao nível do objeto (OLS) determina a que tabelas ou pastas a função pode aceder.
  • A segurança ao nível das linhas (RLS) limita as linhas de uma determinada tabela a que a função pode aceder.
  • A segurança ao nível das colunas (CLS) limita as colunas de uma determinada tabela a que a função pode aceder.

Como os três componentes se aplicam, o OneLake considera a sua interseção. Por exemplo, se o Role1 concede acesso à Tabela1 e restringe as 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 utilizador recebe apenas o acesso permitido por OLS, RLS e CLS nessa função.

Combinar o acesso entre funções

Após resolver cada função, a OneLake combina as funções usando um modelo sindicalizado, ou menos restritivo. O símbolo sindical (∪) significa que o acesso concedido por qualquer função passa a fazer parte do papel efetivo. Se Role1 concede acesso a TableA e Role2 concede acesso a TableB, um utilizador que pertença a ambos os roles pode aceder a ambas as tabelas.

Para duas funções, a função efetiva é:

Effective role = Role1 ∪ Role2

Quando várias funções concedem acesso à mesma tabela, as regras de segurança ao nível da linha combinam-se através de um operador OR. Por exemplo, os predicados que permitem city = 'Redmond' e city = 'New York' combinam-se como city = 'Redmond' OR city = 'New York'.

As regras de segurança ao nível das colunas também se combinam como uma união, exceto no endpoint de análise SQL. No endpoint de análise SQL, o CLS utiliza uma semântica de negação mais rigorosa. Se alguma função ocultar uma coluna, o endpoint bloqueia o acesso a essa coluna. Como resultado, o endpoint faz a interseção das listas de permissões de CLS em todas as funções do utilizador, em vez de as combinar numa união.

Importante

Mantenha as regras RLS e CLS que têm de ser aplicadas em conjunto na mesma função. 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 utilizador não pode pertencer ao Role1, que permite as 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 na localização do atalho. O OneLake cruza o acesso combinado das funções do atalho com o acesso combinado das funções de destino inferidas. Esta 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 dos seus componentes OLS, RLS e CLS antes da OneLake combinar as funções.

Limitações de segurança do OneLake

  • Se tu atribuíres uma função de segurança do OneLake a um utilizador convidado B2B, deverás configurar as tuas definições de colaboração externa para B2B no ID externo Microsoft Entra. Defina a definição de acesso de utilizador convidado para que os utilizadores convidados tenham o mesmo acesso que os membros (mais inclusivo).

  • Se adicionar uma lista de distribuição a uma função na segurança do OneLake, o endpoint de análise SQL não consegue identificar os membros da lista para aplicar o controlo de acesso. Como resultado, os utilizadores parecem não ser membros da função quando acedem ao endpoint de análise SQL. O Direct Lake em modelos semânticos SQL também está sujeito a esta limitação.

  • Os notebooks Spark exigem que o ambiente seja 3.5 ou superior e que utilizem o runtime do Fabric 1.3.

  • Os lakehouses sem esquema não suportam a pré-visualização dos dados para tabelas protegidas por RLS e CLS. Utilize lakehouses com suporte a esquemas e com a segurança do OneLake.

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

  • A tabela seguinte 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 (consulte a nota)
    Número máximo de membros por função de segurança 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 OneLake 500 permissões por função

    Nota

    Pode solicitar um aumento do número de funções por item para 1000. Para solicitar um aumento, contacte 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 que o OneLake aplique as permissões da função no grupo de usuários atualizado. Alguns mecanismos Fabric têm uma camada de cache própria, por isso podem exigir uma hora extra para atualizar o acesso em todos os sistemas.

Conteúdo relacionado

  • Last updated on