Modelo de permissão
O Microsoft Fabric tem um modelo de permissão flexível que permite controlar o acesso aos dados em sua organização. Este artigo explica os diferentes tipos de permissões no Fabric e como eles funcionam juntos para controlar o acesso aos dados em sua organização.
Um espaço de trabalho é uma entidade lógica para agrupar itens no Fabric. As funções de espaço de trabalho definem permissões de acesso para espaços de trabalho. Embora os itens sejam armazenados em um espaço de trabalho, eles podem ser compartilhados com outros usuários no Fabric. Ao compartilhar itens do Fabric, você pode decidir quais permissões conceder ao usuário com quem está compartilhando o item. Determinados itens, como relatórios do Power BI, permitem um controle ainda mais granular dos dados. Os relatórios podem ser configurados para que, dependendo de suas permissões, os usuários que os visualizam vejam apenas uma parte dos dados que possuem.
Funções de workspace
As funções de espaço de trabalho são usadas para controlar o acesso aos espaços de trabalho e o conteúdo dentro deles. Um administrador do Fabric pode atribuir funções de espaço de trabalho a usuários ou grupos individuais. As funções de espaço de trabalho são confinadas a um espaço de trabalho específico e não se aplicam a outros espaços de trabalho, à capacidade em que o espaço de trabalho está ou ao locatário.
Há quatro funções de Espaço de Trabalho e elas se aplicam a todos os itens dentro do espaço de trabalho. Os usuários que não têm nenhuma dessas funções não podem acessar o espaço de trabalho. As funções são:
Espectador - Pode visualizar todo o conteúdo no espaço de trabalho, mas não pode modificá-lo.
Contribuidor - Pode visualizar e modificar todo o conteúdo no espaço de trabalho.
Membro - Pode visualizar, modificar e compartilhar todo o conteúdo no espaço de trabalho.
Administrador - Pode visualizar, modificar, compartilhar e gerenciar todo o conteúdo no espaço de trabalho, incluindo o gerenciamento de permissões.
Esta tabela mostra um pequeno conjunto das capacidades que cada função tem. Para obter uma lista completa e mais detalhada, consulte funções de espaço de trabalho do Microsoft Fabric.
| Recurso | Administrador | Membro | Colaborador | Visualizador |
|---|---|---|---|---|
| Excluir o workspace | ✅ | ❌ | ❌ | ❌ |
| Adicionar administradores | ✅ | ❌ | ❌ | ❌ |
| Adicionar membros | ✅ | ✅ | ❌ | ❌ |
| Gravar dados | ✅ | ✅ | ✅ | ❌ |
| Criar itens | ✅ | ✅ | ✅ | ❌ |
| Ler dados | ✅ | ✅ | ✅ | ✅ |
Permissões de item
As permissões de item são usadas para controlar o acesso a itens individuais do Fabric em um espaço de trabalho. As permissões de item são limitadas a um item específico e não se aplicam a outros itens. Use permissões de item para controlar quem pode visualizar, modificar e gerenciar itens individuais em um espaço de trabalho. Você pode usar permissões de item para conceder a um usuário acesso a um único item em um espaço de trabalho ao qual ele não tem acesso.
Ao compartilhar o item com um usuário ou grupo, você pode configurar permissões de item. O compartilhamento de um item concede ao usuário a permissão de leitura para esse item por padrão. As permissões de leitura permitem que os usuários vejam os metadados desse item e exibam todos os relatórios associados a ele. No entanto, as permissões de leitura não permitem que os usuários acessem dados subjacentes no SQL ou no OneLake.
Diferentes itens do Fabric têm permissões diferentes. Para saber mais sobre as permissões para cada item, consulte:
Permissões de computação
As permissões também podem ser definidas em um mecanismo de computação específico no Fabric, especificamente por meio do ponto de extremidade de análise do SQL ou em um modelo semântico. As permissões do mecanismo de computação permitem um controle de acesso a dados mais granular, como segurança em nível de tabela e linha.
Ponto de extremidade de análise do SQL - O ponto de extremidade de análise do SQL fornece acesso SQL direto a tabelas no OneLake e pode ter a segurança configurada de modo nativo por meio de comandos SQL. Essas permissões só se aplicam a consultas feitas por meio de SQL.
Modelo semântico - Os modelos semânticos permitem que a segurança seja definida usando DAX. As restrições definidas usando o DAX se aplicam aos usuários que consultam por meio do modelo semântico ou dos relatórios do Power BI criados no modelo semântico.
Você pode encontrar mais informações nos seguintes artigos:
Permissões OneLake (funções de acesso a dados)
O OneLake tem suas próprias permissões para governar o acesso a arquivos e pastas no OneLake por meio das funções de acesso a dados do OneLake. As funções de acesso aos dados do OneLake permitem que os usuários criem funções personalizadas dentro de uma lakehouse e concedam permissões de leitura somente para as pastas especificadas ao acessar o OneLake. Os usuários podem atribuir usuários, grupos de segurança ou conceder uma atribuição automática com base na função de espaço de trabalho para cada função do OneLake.
Saiba mais sobre o Modelo de Controle de Acesso a Dados OneLake e veja os guias de instruções.
Ordem de operação
O Fabric tem três níveis de segurança diferentes. Um usuário deve ter acesso em cada nível para acessar os dados. Cada nível é avaliado sequencialmente para determinar se um usuário tem acesso. As regras de segurança, como as políticas de Proteção de Informações da Microsoft, são avaliadas em um determinado nível para permitir ou não o acesso. A ordem de operação ao avaliar a segurança do Fabric é:
- Autenticação do Entra: verifica se o usuário pode se autenticar no locatário do Microsoft Entra.
- Acesso à Fabrci: verifica se o usuário pode acessar o Microsoft Fabric.
- Segurança de dados: verifica se o usuário pode executar a ação solicitada em uma tabela ou arquivo.
Exemplos
Esta seção fornece dois exemplos de como permissões podem ser configuradas no Fabric.
Exemplo 1: Configurando permissões de equipe
A Wingtip Toys é configurada com um locatário para toda a organização e três capacidades. Cada capacidade representa uma região diferente. A Wingtip Toys opera nos Estados Unidos, Europa e Ásia. Cada capacidade tem um espaço de trabalho para cada departamento da organização, incluindo o departamento de vendas.
O departamento de vendas tem um gerente, um líder de equipe de vendas e membros da equipe de vendas. A Wingtip Toys também emprega um analista para toda a organização.
A tabela a seguir mostra os requisitos para cada função no departamento de vendas e como as permissões são configuradas para habilitá-las.
| Função | Requisito | Instalação |
|---|---|---|
| Gerente | Visualizar e modificar todo o conteúdo do departamento de vendas em toda a organização | Uma função de membro para todos os espaços de trabalho de vendas na organização |
| Líder de equipe | Visualizar e modificar todo o conteúdo do departamento de vendas em uma região específica | Uma função de membro para o espaço de trabalho de vendas na região |
| Membro da equipe de vendas | ||
| Analista | Visualizar todo o conteúdo do departamento de vendas em toda a organização | Uma função de espectador para todos os espaços de trabalho de venda na organização |
A Wingtip também tem um relatório trimestral que lista sua receita de vendas por membro de vendas. Esse relatório é armazenado em um espaço de trabalho financeiro. Usando a segurança em nível de linha, o relatório é configurado para que cada membro de vendas só possa ver seus próprios números de vendas. Os líderes de equipe podem ver os números de vendas de todos os membros de vendas em sua região e o gerente de vendas pode ver os números de vendas de todos os membros de vendas na organização.
Exemplo 2: Permissões de espaço de trabalho e item
Quando você compartilha um item ou altera suas permissões, as funções do espaço de trabalho não mudam. O exemplo nesta seção mostra como as permissões de espaço de trabalho e de item interagem.
Verônica e Marta trabalham juntas. Verónica é proprietária de um relatório que ela quer partilhar com Marta. Se Verônica compartilhar o relatório com Marta, Marta poderá acessá-lo independentemente da função que desempenhe no espaço de trabalho.
Digamos que Marta tenha a função de espectadora no espaço de trabalho em que o relatório é armazenado. Se Verônica decidir remover do relatório as permissões de item de Marta, Marta continuará podendo visualizar o relatório no espaço de trabalho. Marta também poderá abrir o relatório no espaço de trabalho e visualizar o seu conteúdo. Isso porque Marta tem permissões de exibição para o espaço de trabalho.
Se Verônica não quiser que Marta exiba o relatório, não será suficiente que ela remova do relatório as permissões de item de Marta. Verônica também precisará remover as permissões de Marta de espectadora do espaço de trabalho. Sem as permissões de espectadora do espaço de trabalho, Marta não poderá ver que o relatório existe, porque não poderá acessar o espaço de trabalho. Marta também não poderá usar o link para o relatório, porque não terá acesso a ele.
Agora que Marta não tem uma função espectadora do espaço de trabalho, se Verônica decidir compartilhar o relatório com ela novamente, Marta poderá exibi-lo usando o link que Verônica compartilhar com ela, sem ter acesso ao espaço de trabalho.
Exemplo 3: permissões do aplicativo Power BI
Ao compartilhar relatórios do Power BI, você geralmente deseja que seus destinatários tenham acesso apenas aos relatórios e não aos itens no espaço de trabalho. Para isso, você pode usar aplicativos do Power BI ou compartilhar relatórios diretamente com os usuários.
Além disso, você pode limitar o acesso do visualizador aos dados usando a segurança em nível de linha (RLS) com o RLS você pode criar funções que têm acesso a determinadas partes de seus dados e limitar os resultados retornando apenas o que a identidade do usuário pode acessar.
Isso funciona bem ao usar modelos de importação, pois os dados são importados no modelo semântico e os destinatários têm acesso a isso como parte do aplicativo. Com o DirectLake, o relatório lê os dados diretamente do Lakehouse e o destinatário do relatório precisa ter acesso a esses arquivos no lago. Você pode fazer isso de várias maneiras:
- Dê a permissão
ReadDatadiretamente no Lakehouse. - Trocar a credencial da fonte de dados do Logon único (SSO) para uma identidade fixa que tem acesso aos arquivos no lago.
Como a RLS é definida no Modelo Semântico, os dados serão lidos primeiro e, em seguida, as linhas serão filtradas.
Se alguma segurança for definida no ponto de extremidade de análise do SQL no qual o relatório é criado, as consultas retornarão automaticamente para o modo DirectQuery. Se você não quiser esse comportamento de fallback padrão, poderá criar um novo Lakehouse usando atalhos para as tabelas no Lakehouse original e não definir RLS ou OLS em SQL no novo Lakehouse.