Como proteger um lakehouse para equipes de Data Warehousing
Introdução
Neste artigo, fornecemos uma visão geral de como configurar a segurança para um lakehouse no Fabric para uso com usuários SQL com consultas T-SQL. Esses usuários podem ser analistas de negócios consumindo dados por meio de SQL, construtores de relatórios ou engenheiros de dados criando novas tabelas e exibições.
Funcionalidades de segurança
O Microsoft Fabric usa um modelo de segurança multicamadas com diferentes controles disponíveis em diferentes níveis para fornecer apenas as permissões mínimas necessárias. Para obter mais informações sobre os diferentes recursos de segurança disponíveis no Fabric, consulte Modelo de controle de acesso a dados no OneLake.
Na carga de trabalho do Fabric Data Warehouse, os itens de ponto de extremidade do warehouse e da análise SQL também permitem a definição de segurança SQL nativa. A segurança SQL usa a biblioteca completa de construções de segurança T-SQL para permitir o controle de acesso granular de tabelas, exibições, linhas e colunas dentro de um item. Para obter mais informações sobre segurança SQL, consulte Permissões granulares do SQL.
As permissões SQL configuradas no depósito ou no ponto de extremidade da análise SQL só se aplicam a consultas executadas no depósito ou no ponto de extremidade da análise SQL. Os dados subjacentes residem no OneLake, mas o acesso aos dados do OneLake é controlado separadamente por meio de funções de acesso a dados do OneLake. Para garantir que os usuários com permissões específicas do SQL não vejam os dados aos quais não têm acesso ao SQL, não inclua esses usuários em uma função de acesso a dados do OneLake.
Seguro por caso de uso
A segurança no Microsoft Fabric é otimizada em torno da proteção de dados para casos de uso específicos. Um caso de uso é um conjunto de usuários que precisam de acesso específico e acessam dados por meio de um determinado mecanismo. Para cenários SQL, alguns casos de uso comuns são:
- Gravadores SQL: usuários que precisam criar novas tabelas, exibir ou gravar dados em tabelas existentes.
- Leitores SQL: usuários que precisam ler dados usando consultas SQL. Eles podem estar acessando a conexão SQL diretamente ou por meio de outro serviço, como o Power BI.
Em seguida, podemos alinhar cada caso de uso com as permissões necessárias no Fabric.
Acesso de gravação SQL
Há duas maneiras de conceder a um usuário acesso de gravação a um depósito ou ponto de extremidade de análise SQL:
- Por meio de funções de espaço de trabalho de malha, você pode conceder associação a três funções de espaço de trabalho que concedem permissões de gravação. Cada função se traduz automaticamente em uma função correspondente no SQL que concede acesso de gravação equivalente.
- Conceda acesso de leitura ao mecanismo SQL e conceda permissões SQL personalizadas para gravar em alguns ou em todos os dados.
Se um usuário precisar de acesso de gravação a todos os armazéns ou pontos de extremidade de análise SQL em um espaço de trabalho, atribua-os a uma função de espaço de trabalho. A menos que um usuário precise atribuir outros usuários a funções de espaço de trabalho, a função de Colaborador deve ser usada.
Se um usuário só precisar gravar em armazéns específicos ou análises SQL, conceda-lhes acesso direto por meio de permissões SQL.
Acesso de leitura SQL
Há duas maneiras de conceder a um usuário acesso de leitura a um depósito ou ponto de extremidade de análise SQL:
- Conceda acesso de leitura por meio da permissão ReadData, concedida como parte das funções do espaço de trabalho Malha. Todas as quatro funções de espaço de trabalho concedem a permissão ReadData.
- Conceda acesso de leitura ao mecanismo SQL e conceda permissões SQL personalizadas para ler alguns ou todos os dados.
Se um usuário for membro de uma função de espaço de trabalho de malha, ele receberá a permissão ReadData. A permissão ReadData mapeia o usuário para uma função SQL que dá permissões SELECT em todas as tabelas no armazém ou lakehouse. Essa permissão é útil se um usuário precisar ver todos ou a maioria dos dados na casa do lago ou no armazém. Todas as permissões SQL DENY definidas em um lago ou armazém específico ainda se aplicam e limitam o acesso às tabelas. Além disso, a segurança em nível de linha e coluna pode ser definida em tabelas para restringir o acesso em um nível granular.
Se um usuário só precisar de acesso a uma casa de lago ou armazém específico, o recurso de compartilhamento fornece acesso apenas ao item compartilhado. Durante o compartilhamento, os usuários podem optar por dar apenas permissão de Ler ou Ler + ReadData. A concessão de permissão de Ler permite que o usuário se conecte ao armazém ou ao ponto de extremidade de análise SQL, mas não dá acesso à tabela. Conceder aos usuários as permissões ReadData dá-lhes acesso de leitura total a todas as tabelas no armazém ou no ponto de extremidade de análise SQL. Em ambos os casos, a segurança SQL adicional pode ser configurada para conceder ou negar acesso a tabelas específicas. Essa segurança SQL pode incluir controle de acesso granular, como segurança em nível de linha ou coluna.
Utilizar com atalhos
Os atalhos são um recurso do OneLake que permite que os dados sejam referenciados de um local sem copiar fisicamente os dados. Os atalhos são uma ferramenta poderosa que permite que os dados de uma casa do lago sejam facilmente reutilizados em outros locais sem fazer cópias duplicadas dos dados.
Os armazéns no Fabric não suportam atalhos. No entanto, há um comportamento especial para como o ponto de extremidade de análise SQL para um lakehouse interage com atalhos.
Todos os atalhos em uma lakehouse são acessados em um modo delegado ao consultar através do ponto de extremidade de análise SQL. A identidade delegada é o usuário do Fabric que possui a lakehouse. Por padrão, o proprietário é o usuário que criou o lakehouse e o ponto de extremidade de análise SQL. O proprietário pode ser alterado em casos selecionados e o proprietário atual é exibido na coluna Proprietário na Malha ao exibir o item na lista de itens do espaço de trabalho. O comportamento delegado significa que um usuário que consulta é capaz de ler a partir de tabelas de atalho se o proprietário tiver acesso aos dados subjacentes, não o usuário que executa a consulta. O usuário que consulta só precisa de acesso para selecionar na tabela de atalhos.
Nota
Por exemplo, UserA é o proprietário de uma lakehouse e UserB está executando uma consulta em uma tabela que é um atalho. UserB deve primeiro ter acesso de leitura na tabela, seja por meio de ReadData ou por meio de permissões SQL. Para ver os dados, a consulta verifica se UserA tem acesso ao atalho. Se UserA tiver acesso, UserB verá os resultados da consulta. Se UserA não tiver acesso, a consulta falhará.
Para lakehouses que usam o recurso de funções de acesso a dados do OneLake, o acesso a um atalho é determinado pelo fato de o proprietário do ponto de extremidade de análise SQL ter acesso para ver o lakehouse de destino e ler a tabela por meio de uma função de acesso a dados do OneLake.
Para lakehouses que ainda não estão usando o recurso de funções de acesso a dados do OneLake, o acesso de atalho é determinado pelo fato de o proprietário do ponto de extremidade de análise SQL ter a permissão Ler e ReadAll no caminho de destino.