Segurança do OneLake para endpoints de análise SQL (Pré-visualização)

Com a segurança da OneLake, o Microsoft Fabric está a expandir a forma como as organizações podem gerir e impor o acesso a dados entre cargas de trabalho. Essa nova estrutura de segurança dá aos administradores maior flexibilidade para configurar permissões. Os administradores podem escolher entre governança centralizada por meio do OneLake ou controle granular baseado em SQL dentro do endpoint de análise SQL.

Modos de Acesso no endpoint de análise SQL

Ao usar o endpoint de análise SQL, o modo access selecionado determina como a segurança dos dados é aplicada. A Fabric suporta dois modelos de acesso distintos, cada um oferecendo benefícios diferentes dependendo das suas necessidades operacionais e de conformidade:

• Modo de identidade do usuário: Impõe a segurança usando funções e políticas do OneLake. Neste modo, o endpoint de análise SQL passa a identidade do utilizador com sessão iniciada para o OneLake, e o acesso de leitura é totalmente regido pelas regras de segurança definidas no OneLake. Há suporte para permissões no nível SQL em tabelas, garantindo governança consistente em ferramentas como Power BI, blocos de anotações e lakehouse.

• Modo de identidade delegada: fornece controle total por meio de SQL. Nesse modo, o ponto de extremidade de análise SQL conecta-se ao OneLake usando a identidade do proprietário do espaço de trabalho ou do item e a segurança é regida exclusivamente por permissões SQL definidas dentro do banco de dados. Este modelo suporta abordagens de segurança tradicionais, incluindo GRANT, REVOKE, funções personalizadas, Segurança Row-Level e Mascaramento Dinâmico de Dados.

Cada modo suporta diferentes modelos de governança. Entender as suas implicações é essencial para escolher a abordagem correta no seu ambiente Fabric.

Comparação entre modos de acesso

Aqui está uma tabela comparativa clara e concisa, focada em como e onde definir a segurança no modo de identidade do utilizador versus modo de identidade delegada — dividida por tipo de objeto e políticas de acesso aos dados:

Modo de identidade do usuário na segurança do OneLake

No modo de identidade do utilizador, o endpoint de análise SQL utiliza um mecanismo de autenticação por passagem direta para impor o acesso aos dados. Quando um utilizador se conecta ao ponto de extremidade de análise SQL, a sua identidade Entra ID é passada para o OneLake, que realiza a verificação de permissão. Todas as operações de leitura em tabelas são avaliadas usando as regras de segurança definidas no OneLake Lakehouse, não por nenhuma instrução GRANT ou REVOKE de nível SQL.

Este modo permite gerir a segurança centralmente, garantindo uma aplicação consistente em todas as experiências da plataforma Fabric, incluindo Power BI, notebooks, lakehouse e endpoint de análise SQL. Foi concebido para modelos de governação onde o acesso deve ser definido uma vez no OneLake e automaticamente respeitado em qualquer lugar.

No modo de identidade do usuário:

• O acesso à mesa é totalmente regulado pela segurança da OneLake. As instruções SQL GRANT/REVOKE em tabelas são ignoradas.

• RLS (Row-Level Security), CLS (Column-Level Security) e Object-Level Security são todos definidos na experiência OneLake.

• As permissões SQL são permitidas para objetos que não são de dados, como modos de exibição, procedimentos armazenados e funções, permitindo flexibilidade para definir lógica personalizada ou pontos de entrada de dados voltados para o usuário.

• Não há suporte para operações de gravação no ponto de extremidade de análise SQL. Todas as escritas devem ocorrer através da página Lakehouse no portal Fabric e são regidas por funções de espaço de trabalho (Administrador, Membro, Contribuidor).

Comportamento do papel no espaço de trabalho

Os usuários com a função de Administrador, Membro ou Colaborador no nível do espaço de trabalho não estão sujeitos à imposição de segurança do OneLake. Essas funções têm privilégios elevados e ignorarão totalmente as políticas de RLS, CLS e OLS. Siga estes requisitos para garantir que a segurança do OneLake seja respeitada:

• Atribua aos usuários a função Visualizador no espaço de trabalho ou

• Compartilhe o ponto de extremidade de análise do Lakehouse ou do SQL com os utilizadores usando permissões somente leitura. Apenas os utilizadores com acesso apenas de leitura têm as suas consultas filtradas de acordo com os papéis de segurança da OneLake.

Precedência de funções: O acesso mais permissivo prevalece

Se um utilizador pertence a múltiplas funções OneLake, a função mais permissiva define o seu acesso efetivo. Por exemplo:

• Se uma função conceder acesso total a uma tabela e outra aplicar RLS para restringir linhas, o RLS não será imposto.

• O papel de acesso mais amplo tem prioridade. Esse comportamento garante que os usuários não sejam bloqueados involuntariamente, mas requer um design de função cuidadoso para evitar conflitos. Recomenda-se manter papéis restritivos e permissivos mutuamente exclusivos ao impor controlos de acesso ao nível de linhas ou colunas.

Para mais informações, consulte o modelo de controlo de acesso de dados para a segurança do OneLake.

Sincronização de segurança entre o OneLake e o endpoint de análise SQL

Um componente crítico do modo de identidade do usuário é o serviço de sincronização de segurança. Esse serviço em segundo plano monitora as alterações feitas nas funções de segurança no OneLake e garante que essas alterações sejam refletidas no endpoint da analítica SQL.

O serviço de sincronização de segurança é responsável pelo seguinte:

• Deteção de alterações nas funções do OneLake, incluindo novas funções, atualizações, atribuições de usuário e alterações em tabelas.

• Tradução de políticas definidas pelo OneLake (RLS, CLS, OLS) em estruturas de função de banco de dados equivalentes compatíveis com SQL.

• Garantir que os objetos de atalho (tabelas provenientes de outras casas de lago) sejam devidamente validados para que as configurações de segurança originais do OneLake sejam respeitadas, mesmo quando acessadas remotamente.

Essa sincronização garante que as definições de segurança do OneLake permaneçam autoritativas, eliminando a necessidade de intervenção manual no nível SQL para replicar o comportamento de segurança. Porque a segurança é imposta centralmente:

• Não é possível definir RLS, CLS ou OLS diretamente usando T-SQL neste modo.

• Você ainda pode aplicar permissões SQL a modos de exibição, funções e procedimentos armazenados usando instruções GRANT ou EXECUTE.

Erros de sincronização de segurança e resolução

Comportamento dos atalhos com sincronização segura

A segurança do OneLake é garantida na fonte única de dados, portanto, a sincronização da segurança desativa o encadeamento de propriedade para tabelas e visualizações que envolvem atalhos. Isso garante que as permissões do sistema de origem sejam sempre avaliadas e respeitadas, mesmo para consultas de outro banco de dados.

Como resultado:

• Os utilizadores devem ter acesso válido em ambos do atalho source (endpoint atual de análise Lakehouse ou SQL) e o destino onde os dados residem fisicamente.

• Se o utilizador não tiver permissão em qualquer dos lados, as consultas falharão com um erro de acesso.

• Ao projetar seus aplicativos ou exibições que fazem referência a atalhos, certifique-se de que as atribuições de função estejam configuradas corretamente em ambas as extremidades da relação de atalho.

Este design preserva a integridade de segurança em toda a extensão do Lakehouse, mas introduz cenários nos quais podem ocorrer falhas de acesso se as funções entre os Lakehouses não estiverem alinhadas.

Modo delegado na segurança do OneLake

Em Modo de Identidade Delegada, o endpoint de análise SQL utiliza o mesmo modelo segurança que existe hoje em Microsoft Fabric. A segurança e as permissões são geridas inteiramente na camada SQL, e os papéis ou políticas de acesso do OneLake não são aplicados para acesso ao nível da tabela. Quando um utilizador se conecta ao endpoint de análise SQL e emite uma consulta:

• O SQL valida o acesso com base em permissões SQL (GRANT, REVOKE, RLS, CLS, DDM, funções, etc.).

• Se a consulta for autorizada, o sistema prossegue para aceder aos dados armazenados em OneLake.

• O acesso a dados é realizado usando a identidade do proprietário do endpoint Lakehouse ou SQL Analytics — também conhecido como conta do item.

Neste modelo:

• O usuário conectado não é passado para o OneLake.

• Presume-se que todo o controlo do acesso seja efetuado na camada SQL.

• O proprietário do item é responsável por ter permissões suficientes no OneLake para ler os arquivos subjacentes em nome da carga de trabalho.

Como este é um padrão delegado, qualquer desalinhamento entre as permissões SQL e o acesso OneLake para o proprietário resulta em falhas de consulta. Este modo fornece total compatibilidade com:

• SQL GRANT/REVOKE em todos os níveis de objeto

• Segurança ao nível de linhas, Segurança ao nível de colunas, e Mascaramento dinâmico de dados

• Ferramentas e práticas T-SQL existentes usadas por DBAs ou aplicativos

Como mudar o modo de acesso OneLake

O modo de acesso determina como o acesso aos dados é autenticado e aplicado ao consultar o OneLake através do ponto final de análise SQL. Você pode alternar entre o modo de identidade do usuário e o modo de identidade delegada usando as seguintes etapas:

1. Navegue até o espaço de trabalho do Fabric e abra a casa do lago. No canto superior direito, mude de lakehouse para endpoint de análise SQL.

2. Na navegação superior, vá ao separador Security e selecione um dos seguintes modos de access OneLake:

   • Identidade do usuário – Usa a identidade do usuário conectado. Ele impõe funções OneLake.

   • Identidade delegada – Usa a identidade do proprietário do item; impõe apenas permissões SQL.

3. Um pop-up abre para confirmar a sua seleção. Selecione Sim para confirmar a alteração.

Considerações ao alternar entre modos

Mudar para o modo de identidade do utilizador

• As permissões SQL RLS, CLS e de nível de tabela são ignoradas.

• Os papéis OneLake devem ser configurados para que os utilizadores mantenham o acesso.

• Apenas os utilizadores com permissões de visualização ou acesso partilhado apenas de leitura estarão sujeitos à segurança da OneLake.

• As funções SQL existentes são excluídas e não podem ser recuperadas.

Mudar para o modo de identidade delegada

• As funções e políticas de segurança do OneLake não são mais aplicadas.

• As funções SQL e as políticas de segurança tornam-se ativas.

• O proprietário do item deve ter um acesso válido ao OneLake, caso contrário todas as consultas podem falhar.

Limitações

• Aplica-se apenas a leitores: a segurança da OneLake regula o acesso dos utilizadores aos dados como Visualizadores. Utilizadores noutras funções de espaço de trabalho (Administrador, Membro ou Contribuidor) contornam a segurança do OneLake e mantêm acesso total.

• Os objetos SQL não herdam propriedade: os atalhos são apresentados no ponto de extremidade da análise SQL como tabelas. Ao acessar essas tabelas, diretamente ou por meio de modos de exibição, procedimentos armazenados e outros objetos SQL derivados não carregam propriedade no nível do objeto; Todas as permissões são verificadas em tempo de execução para evitar o desvio de segurança.

• As alterações de atalho acionam o tempo de inatividade da validação: quando um destino de atalho é alterado (por exemplo, renomear, atualizar URL), o banco de dados entra brevemente no modo de usuário único enquanto o sistema valida o novo destino. Durante esse período, as consultas são bloqueadas, essas operações são bastante rápidas, mas às vezes, dependendo de diferentes processos internos, podem levar até 5 minutos para serem sincronizadas.

  • A criação de atalhos de esquema pode causar um erro conhecido que afeta a validação e atrasa a sincronização de metadados.

• Propagação de permissão atrasada: as alterações de permissão não são instantâneas. A alternância entre os modos de segurança (Identidade do Usuário vs. Delegado) pode exigir tempo para se propagar antes de entrar em vigor, mas deve levar menos de 1 minuto.

• Dependência do plano de controle: as permissões não podem ser aplicadas a usuários ou grupos que ainda não existem no plano de controle do espaço de trabalho. Você precisa compartilhar o item de origem, ou o utilizador deve ser membro da função de Visualizador no espaço de trabalho. Observe que exatamente o mesmo ID de objeto deve estar em ambos os lugares. Um grupo e um membro desse grupo não contam como uma combinação.

• O acesso mais permissivo prevalece: Quando os utilizadores pertencem a múltiplos grupos ou funções, a permissão efetiva mais permissiva é respeitada Exemplo: Se um utilizador tiver tanto NEGAR através de uma função como CONCEDER por outra, o CONCEDER tem prioridade.

• Limitações do modo Delegado: No modo Delegado, a sincronização de metadados nas tabelas de atalhos pode falhar se o item de origem tiver políticas de segurança do OneLake que não concedam acesso completo ao dono do item.

• Comportamento de NEGAR: Quando múltiplos papéis se aplicam a uma única tabela de atalhos, a interseção das permissões segue a semântica do SQL Server: NEGAR sobrepõe-se a CONCEDER. Isto pode produzir resultados de acesso inesperados.

• Condições de erro esperadas: Os usuários podem encontrar erros em cenários como:

  • Destino de atalho renomeado ou inválido

    • Exemplo: Se a fonte da tabela foi excluída.

  • Configuração incorreta de RLS (Row-Level Security)

    • Algumas expressões para filtragem RLS não são suportadas no OneLake e pode permitir acesso não autorizado a dados.

    • Eliminar a coluna usada na expressão do filtro invalida o RLS e a Sincronização de Metadados ficará obsoleta até que o RLS seja corrigido no painel de segurança do OneLake.

    • Para visualização pública, suportamos apenas tabelas de expressão única. Dynamic RLS e Multi-Table RLS não são suportados no momento.

  • Limitações do Column-Level Security (CLS)

    • CLS funciona mantendo uma lista de permissões de colunas. Se uma coluna permitida for removida ou renomeada, a política CLS se tornará inválida.

    • Quando o CLS é inválido, a sincronização de metadados é bloqueada até que a regra CLS seja corrigida no painel de segurança do OneLake.

  • Falha na sincronização de metadados ou permissões

    • Se houver alterações na tabela, como renomear uma coluna, a segurança não será replicada no novo objeto e você receberá erros de interface do usuário mostrando que a coluna não existe.

• A renomeação das tabelas não preserva as políticas de segurança: Se os papéis de segurança (OLS) da OneLake estiverem definidos ao nível do Esquema, esses papéis permanecem em vigor apenas enquanto o nome da tabela permanecer inalterado. Renomear a tabela quebra a associação e as políticas de segurança não serão migradas automaticamente. Isso pode resultar em exposição não intencional de dados até que as políticas sejam reaplicadas.

• As funções de segurança do OneLake não podem ter nomes com mais de 124 caracteres; Caso contrário, a Sincronização de Segurança não poderá sincronizar as funções.

• As funções de segurança do OneLake são propagadas no ponto final de análise SQL com o prefixo OLS_.

• Não há suporte para alterações de usuário nas funções OLS_ e podem causar comportamentos inesperados.

• Não há suporte para grupos de segurança habilitados para email e listas de distribuição.

• O proprietário do lakehouse deve ser um membro das funções de administrador, membro ou colaborador do espaço de trabalho; caso contrário, a segurança não será aplicada ao ponto final de análise SQL.

• O proprietário da residência lacustre não pode ser uma entidade de serviço para que a sincronização de segurança funcione.

Conteúdo relacionado

• Práticas recomendadas para proteger dados no OneLake
• modelo de controlo de acesso de segurança OneLake