Este artigo do blog poderia ser chamado de “Uma solução melhor para o compartilhamento de Dataflows no Power BI via Workspace”, pois ele adota uma perspectiva de quem é familiarizado com o Power BI, mas aprofunda a implementação do OLS (segurança em nível de objeto) e/ou RLS (segurança em nível de linha) para compartilhar dados por meio do Ponto de extremidade do SQL ou de um Warehouse no Microsoft Fabric.

Neste artigo, o foco será o artefato item “LakeHouse” como substituto para os Dataflows (fluxos de dados do Power BI), mas também pode ser aplicado ao item Warehouse. Se você não estiver familiarizado com o SQL, não se preocupe, pois este artigo tem o objetivo de fornecer uma compreensão básica.

O Problema do Compartilhamento de Dados (Dataflow)

Para aqueles de nós que vieram do mundo do Power BI, onde apenas o Power BI estava disponível, o uso dos Dataflows do Power BI era o padrão-ouro para reutilizar nossos processos ETL (extração, transformação, carga) e alavancá-los tanto para utilizar o processamento da nuvem do Power BI Serviço (dando aos analistas a liberdade de agendar e executar fluxos automatizados) quanto como fonte de dados para reutilização, seguindo o Máxima de Roche:

“Os dados devem ser transformados o mais a montante  possível e o mais a jusante quanto necessário”

Aqui “montante” seria mais próximo da origem possível e “jusante” mais próximo do consumo possível.

Embora os Dataflows do Power BI tenham sido uma bênção em termos de arquitetura quando lançado, permitindo ao analista ter um ponto mais a “montante” dentro do Power BI Serviço, eles introduziram alguns problemas tecnológicos. O principal problema era configurar permissões para compartilhar dados por meio de um Dataflow como fonte de dados, o que só podia ser feito no nível do workspace.

Isso não é ideal. No mundo real, planejar quais itens devem ser adicionados a quais workspaces pode ser inconsistente, porque os usuários frequentemente veem os workspaces como pastas do SharePoint de departamentos, em vez de contêineres por processo, apesar das orientações de Melissa.

Compartilhar em nível de workspace significa que, se você quiser compartilhar dados contidos em um Dataflow, precisará conceder acesso a todos os outros itens (existentes e futuros) do workspace.

Isso leva a compartilhar conteúdo em excesso com as pessoas ou ser obrigado a criar workspaces separados apenas para compartilhar os dados que um usuário tem permissão para ver. Essa proliferação de workspaces pode ser ainda pior se você tiver requisitos de OLS (significando que nem todas as tabelas dentro de um Dataflow podem ser vistas pelo usuário) ou RLS (significando que nem todas as linhas dentro de uma tabela estão disponíveis para o usuário).

O Microsoft Fabric traz novas opções

Com a introdução do Microsoft Fabric, muitos recursos empolgantes foram introduzidos para aqueles que anteriormente tinham acesso apenas ao Power BI Serviço. Esses recursos fornecem ferramentas mais profissionais e escaláveis para processos adequados de ETL / ELTL, ao invés de ter disponível apenas do Power Query (e da linguagem M). O Fabric permite o uso de outras linguagens, como SQL, Python, R e muito mais. Em um projeto, você pode aproveitar a especialização dos membros da sua equipe e usar diferentes ferramentas para extração e transformação, reduzindo o tempo necessário para implementar novos projetos. Como o Fabric é uma extensão do Power BI (compartilhando a plataforma Power BI Premium), a maioria dos itens, no momento em que escrevo, só pode ser compartilhados no nível do workspace. No entanto, isso pode mudar rapidamente, pois o Fabric recebe novos recursos todas as semanas.

O Princípio do Menor Privilégio

O “princípio do menor privilégio” deve ser nosso mantra, especialmente ao lidar com dados altamente confidenciais. Isso significa seguir o conselho de Melissa ao planejar os itens do workspace. Você deve ser muito criterioso sobre quem terá funções de membro/contribuidor.

Não é recomendado dar funções de visualizador no nível do workspace, porque os usuários ganharão acesso imediato a todos os itens atuais e futuros criados nesse workspace, incluindo Conjuntos de Dados, Relatórios e Dataflows. LakeHouses/Warehouses são uma exceção, como explicaremos mais adiante.

Mas eu não deveria compartilhar conteúdo através de APPs?

No mundo do Power BI, o cenário ideal é compartilhar itens por meio de APPs. No entanto, o foco do compartilhamento por APPs é compartilhar relatórios/painéis, é como se fosse uma praça de alimentação onde os clientes podem escolher entre todo o conteúdo selecionado para eles acessarem em um único lugar, em vez de ir a vários locais diferentes para consumir análises diferentes.

O foco do APP é no consumo de conteúdo pré-criado no nível de tomada de decisão. Embora isso ajude, não atende a todas as necessidades do analista de dados, pois eles muitas vezes precisam combinar informações para realizar análises personalizadas. Eles são uma classe especial de consumidores que realmente precisam ir ao supermercado para fazer sua própria receita, não apenas ir ao restaurante, ou praça de alimentação.

Compartilhamento “por item” resolve o problema do compartilhamento de dados

A solução para esse problema está no compartilhamento “por item”. Conceda aos usuários acesso apenas ao item específico que eles precisam, nada mais. Isso está alinhado com o princípio do menor privilégio. Os usuários podem usar o hub de dados OneLake, uma ferramenta de catálogo de dados dentro do Microsoft Fabric, onde o analista pode procurar fontes de dados disponíveis. Eles podem se beneficiar da camada semântica completa de um conjunto de dados(dataset) ou ter acesso aos dados por meio do ponto de extremidade do SQL (SQL Endpoint) ou do Warehouse.

Uma observação é que você pode configurar um Conjunto de Dados do Power BI com OLS/RLS configurados e compartilhá-lo de forma semelhante ao compartilhamento de um Dataflow, mas isso requer Power BI Premium por capacidade ou por usuário para conectar-se e consultar dados por meio do XMLA, ou algumas ginásticas com o Power Automate, como fez Štěpán para extrair dados de datasets via Power Automate. Em resumo, essa alternativa requer um alto nível de conhecimento para integrar as coisas e pode não ser adequado para todos os usuários que consomem altos volumes de dados.

O OneSecurity ainda não está disponível, mas as opções disponíveis são muito boas!

O Fabric, que ainda está em public preview, então as coisas podem mudar um pouco, mas já permite que você compartilhe apenas aquele item específico do workspace para LakeHouses e WareHouses, por exemplo, como gostaríamos ter disponível desde o dia em que os Dataflows surgiram no Power BI.

Isso não é ainda o recurso anunciado do OneSecurity, onde a segurança será configurada uma única vez no nível de armazenamento do OneLake. Isso será o recurso “matador” do Fabric assim que for lançado, proporcionando tranquilidade para aqueles que trabalham diariamente com dados altamente confidenciais.

A maneira disponível de aplicar a segurança agora é no nível do motor de cálculo que tem acesso aos dados e os entregam aos usuários. Os principais motores do Fabric são o Apache Spark para engenharia de dados e ciência de dados, o SQL para transformação e consultas de dados, o Analysis Services para modelagem semântica e o Kusto para análise em tempo real.

Para manter o escopo deste artigo que já está longo, vamos voltar para a alternativa ao Dataflow: o item LakeHouse

Quando você cria um LakeHouse, você obtém dois itens adicionais com ele: o ponto de extremidade SQL e o conjunto de dados (padrão). É como se fosse aquela promoção de compre um, leve três. Espero que isso mude no futuro, pois os usuários comuns não precisam saber que o SQL Endpoint é uma implementação especial do item Warehouse com recursos de somente leitura em SQL. Saber que o LakeHouse pode ser lido através do SQL ou do Analysis Services deveria ser suficiente.

A propósito, ter uma string de conexão SQL é muito melhor para compartilhar dados para consumo externo do que via Dataflows ou Conjuntos de Dados para fins de ingestão de dados. Isso permite o compartilhamento seguro com todos os motores de cálculo existentes no mercado, não apenas os da Microsoft.

É importante lembrar que um dos pilares do Fabric é a separação do armazenamento e do cálculo dos vários motores de cálculo. OneLake é o local de armazenamento unificado, e todo motor de cálculo do Fabric pode ler e escrever nele. Na verdade, qualquer outro motor de cálculo capaz de ler tabelas delta (open source), por exemplo o Databricks, pode ler e gravar no OneLake através das APIs.

• Os arquivos de armazenamento (tabelas delta) podem ser acessados pelo item LakeHouse no OneLake por meio das APIs ADLS Gen2 ou do motor de cálculo do Apache Spark no Fabric.
• O Ponto de extremidade do SQL ou os itens Warehouse representam o motor de cálculo do SQL no Fabric.
• O item de Conjunto de Dados (padrão) representa o motor de cálculo Analysis Services no Fabric (que é o mesmo usado pelo Power BI).

Agora, vamos prosseguir para o ponto das permissões.

Ao compartilhar o item LakeHouse, você pode conceder apenas a permissão de leitura Ler ou marcar caixas específicas que dão aos usuários mais privilégios.

Se lembra do princípio do menor privilégio? Por padrão, você nunca deve marcar essas opções de permissões adicionais.

Se você não selecionar nenhuma dessas opções, estará concedendo apenas permissão Ler aos motores SQL e Analysis Services. Isso significa:

• No nível SQL, você permite que o usuário se conecte ao ponto de extremidade do SQL do item e nada mais.
• No nível Analysis Services, você permite que as pessoas vejam os dados que foram criados para elas por meio de um Relatório. Aqui, o usuário pode ver todos os dados, a menos que você configure permissões no nível do conjunto de dados padrão, o que ainda não está disponível no momento.

Ambos os motores do SQL e Analysis Services usam atualmente a identidade do criador do item para acessar os dados. Portanto, é crucial ter cuidado no compartilhamento se você estiver lidando com dados confidenciais.

• Se você marcar a caixa Ler todos os dados do ponto de extremidade de SQL, estará concedendo a permissão ReadData ao motor do SQL. Isso significa que você está concedendo acesso a todos os objetos (tabelas ou views) nele e a capacidade do usuário de criar suas próprias consultas.
• Se você marcar a caixa Ler tudo do Apache Spark, estará concedendo a permissão ReadAll, que permite ao usuário acessar as tabelas e arquivos (o armazenamento real do OneLake) do seu LakeHouse. Atualmente, você só pode acessar dados usando a API do OneLake para exportar dados para usar um motor externo para executar alguma tarefa ou o Apache Spark para executar notebooks(blocos de anotações) em tarefas de engenharia de dados ou ciência de dados.
• Se você marcar a caixa Criar relatórios no conjunto de dados padrão, estará concedendo ao usuário a permissão de Build no motor do Analysis Services, permitindo que o usuário se conecte ao seu Analysis Services e crie suas próprias Consultas DAX ou um relatório do Power BI (que pode ser descrito como um gerador de Consultas DAX automáticas) com base nele.

Implementando OLS em um Ponto de extremidade do SQL ou Warehouse do Fabric

Voltando à parte do SQL, se você conceder apenas a permissão de leitura (Ler), estará seguindo o princípio do menor privilégio. Conceder ReadData significa que você não está. Lembre-se de que Ler significa que o usuário pode se conectar, mas não pode ver nenhum objeto (tabela ou view). Por outro lado, ReadData concede permissões para ver todos os objetos disponíveis por padrão.

O Fabric atualmente não possui uma interface bonita (talvez nunca tenha) para selecionar quais objetos você está permitindo ou negando que os usuários vejam no motor do SQL. Se você é uma pessoa do Power BI como eu, é aqui que as coisas ficam nebulosas. Aqui eu realmente precisei da ajuda do meu amigo Jonatan Torres para me socorrer.

Para simplificar, basta abrir a consulta SQL e digitar o código

É realmente simples. Abra o ponto de extremidade do SQL ou o item Warehouse, clique em Nova consulta SQL e digite e execute o código desejado.

• As strings usam ‘aspas simples’
• Os comentários são feitos com —
• Todas as tabelas ou views estão disponíveis em Schemas -> DBO
• Você pode renomeá-lo e movê-lo para consultas compartilhadas para uso posterior pela sua equipe
• Você pode selecionar parte do código e clicar em Executar (ou ctrl+enter) para executar aquela parte do código (necessário se houver variações do mesmo código).

Controlando as permissões OLS com a permissão de Leitura

Se o usuário (ou grupo de segurança) tiver a permissão de leitura para o Ponto de extremidade do SQL ou o item Warehouse, você deve adicionar (GRANT) os objetos que eles podem ver.

— Para conceder a capacidade ao usuário de criar consultas SELECT sobre o objeto
GRANT SELECT ON dbo.TabelaOuExibicaoRestrita TO [userOne@contoso.com];

— Para conceder a capacidade ao grupo de segurança de criar consultas SELECT sobre o objeto
GRANT SELECT ON dbo.TabelaOuExibicaoRestrita TO [Nome do Grupo de Segurança];

— Para conceder a capacidade ao papel de criar consultas SELECT sobre o objeto
GRANT SELECT ON dbo.TabelaOuExibicaoRestrita TO [Nome da função];

Controlando as permissões OLS com a permissão de ReadData

Se eles tiverem a permissão ReadData, você pode restringir (DENY) o acesso aos objetos que eles não podem ver. Aqui você deve ter cuidado com as permissões dos novos objetos adicionados.

— Para NEGAR a capacidade do usuário de criar consultas SELECT sobre o objeto
DENY SELECT ON dbo.TabelaProibida TO [userOne@contoso.com];

— Para NEGAR a capacidade do grupo de segurança de criar consultas SELECT sobre o objeto
DENY SELECT ON dbo.TabelaProibida TO [Nome do Grupo de Segurança];

–Para NEGAR a capacidade do papel de criar consultas SELECT sobre o objeto
DENY SELECT ON dbo.TabelaProibida TO [Nome da função];

Removendo permissões ou restrições anteriores

Sempre que desejar remover uma permissão ou negação concedida anteriormente, você deve usar REVOKE em vez de DENY ou GRANT.

Como criar e atribuir usuários a funções

Para criar uma nova função (uma prática recomendada para conceder acesso), use o comando:

CREATE ROLE FuncaoPrivilegiada;

Em seguida, você pode atribuir membros (usuários ou grupos de segurança) a essa função usando o comando:

ALTER ROLE FuncaoPrivilegiada ADD MEMBER [userOne@contoso.com];

ALTER ROLE FuncaoPrivilegiada ADD MEMBER [Grupo de Segurança];

Implementando RLS em um Ponto de extremidade do SQL ou Warehouse no Fabric

Ainda não existe uma solução RLS nativa, mas pode aproveitar o objeto View para emular uma.

Para aqueles que não estão familiarizados com o termo, uma View é como uma tabela virtual, uma consulta pré-montada que pode ser usada para encapsular consultas complexas, fornecer uma camada de abstração, ou restringir o acesso aos dados subjacentes. É como se fosse uma consulta DAX.

Aqui você dá ao usuário o acesso GRANT SELECT apenas para a VIEW, não para a tabela original.

A implementação real de RLS é escrita na cláusula WHERE da sua VIEW:

• RLS estático usando Funções: abordagem SUSER_SNAME() (que retorna o e-mail do usuário atual)
• RLS dinâmico usando o e-mail do usuário: abordagem IS_MEMBER(‘Função privilegiada’) = 1 (que testa se o e-mail do usuário é membro de um perfil).

Para criar uma view, você pode usar o seguinte código:

CREATE VIEW [dbo].[Nome da View] as
SELECT *
FROM dbo.TabelaAmostra
WHERE
–Aqui você aplica a regra RLS no nível do usuário, aplicando RLS Dinâmico
( SUSER_SNAME() = ‘usuarioDois@contoso.com’ AND regiao_teste = ‘nome_regiao_um’)
OR
–Aqui você aplica a regra RLS no nível de função, aplicando RLS Estático
( IS_MEMBER(‘FuncaoPrivilegiada’) = 1 AND regiao_teste = ‘nome_regiao_dois’);

Para alterar uma view, você pode usar a interface do usuário para ajudá-lo.

Infelizmente, o comando EXECUTE AS não está disponível no motor do SQL do Fabric neste momento. Seria bom para poder executar uma consulta como um usuário específico e testar se as políticas de segurança OLS/RLS foram aplicadas com sucesso.

Estou perdido. Como eu controlo as permissões OLS que eu já dei?

Depois de executar vários comandos, pode ser fácil se perder. Então, se você é membro ou administrador do Workspace, você pode sempre executar o comando para ver as permissões detalhadas atuais para os objetos:

SELECT DISTINCT   pr.name, pr.type_desc, pe.state_desc, pe.permission_name, pe.class_desc, obj.name AS object_name,  obj.modify_date

FROM sys.database_principals AS pr

JOIN sys.database_permissions AS pe

    ON pe.grantee_principal_id = pr.principal_id

LEFT JOIN sys.objects AS obj

    ON pe.major_id = obj.object_id

WHERE

    permission_name = ‘SELECT’

—    AND pr.name = ‘Nome do Grupo de Segurança’

e para ver quais membros pertencem a cada função:

SELECT p.name AS NomeFuncao, m.name AS NomeMembro, m.type_desc as TipoUsuario, m.create_date as DataCriacao, m.modify_date as DataModificacao, m.authentication_type_desc as TipoAutenticacao

FROM sys.database_role_members drm

JOIN sys.database_principals p ON drm.role_principal_id = p.principal_id

JOIN sys.database_principals m ON drm.member_principal_id = m.principal_id

–WHERE p.name = ‘Funcao’;

Como os usuários finais devem consumir esses dados?

Todo Workspace do Fabric tem uma string de conexão SQL única. Este endereço é um pouco longo ( ifrg6w2xtlsexdsqdx5hfk4-qwusgtsg42lefayozohosi.datawarehouse.pbidedicated.windows.net ), mas felizmente, o Power BI Desktop tem uma interface muito melhor para procurá-lo no hub de dados do OneLake. Por padrão, eles tentarão conectá-lo ao conjunto de dados padrão do LakeHouse (se você tiver permissão de build), mas você pode mudar para se conectar ao seu ponto de extremidade do SQL, que automaticamente encontra o endereço para você.

Outra forma de obter o endereço pode ser realizar a cópia deste endereço do workspace clicando no … do item Ponto de extremidade do SQL.

Conclusão

Espero que este artigo ajude você a arquitetar melhores soluções seguras no Microsoft Fabric, já que o item LakeHouse oferece uma maneira muito poderosa de compartilhar os dados certos com as pessoas certas de forma segura através do SQL.

Esta é uma alternativa muito melhor do que usar os Dataflows do Power BI como fonte de dados. Ao compartilhar através do motor SQL, você pode ter OLS e emular RLS usando um motor universalmente aceito para compartilhar grandes volumes de dados de forma segura.

A falta de uma interface de usuário adequada para isso pode assustar os novatos como eu, mas depois de um tempo, é mais fácil se acostumar com isso, especialmente se você salvar as principais consultas de controle em consultas compartilhadas.

PS1: Estou realmente ansioso para ver a implementação do OneSecurity que pode mudar tudo para melhor, porque quando você define a segurança no nível do motor, pode haver lacunas entre o que o usuário vê dependendo de qual motor ele está usando.

PS2: A maneira padrão de compartilhar conteúdo dentro do Fabric é através de atalhos. Isso evita a duplicação desnecessária dos mesmos dados, mas temo que só seja viável compartilhar dados confidenciais com OLS/RLS quando o OneSecurity estiver totalmente implementado, pois a implementação da segurança vai ser a nível de armazenamento, e não motor.