Segurança do OneLake para pontos de extremidade de análise de SQL (versão prévia)

Com a segurança do OneLake, o Microsoft Fabric está expandindo como as organizações podem gerenciar e impor o acesso a dados entre cargas de trabalho. Essa nova estrutura de segurança oferece aos administradores maior flexibilidade para configurar permissões. Os administradores podem escolher entre a governança centralizada por meio do OneLake ou o controle baseado em SQL granular no ponto de extremidade de análise do SQL.

Modos de acesso no ponto de extremidade de análise do SQL

Ao usar o ponto de extremidade de análise do SQL, o modo de acesso selecionado determina como a segurança de dados é imposta. O Fabric dá suporte a dois modelos de acesso distintos, cada um oferecendo benefícios diferentes dependendo de 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. Nesse modo, o ponto de extremidade de análise do SQL passa a identidade do usuário conectado para o OneLake e o acesso de leitura é regido inteiramente pelas regras de segurança definidas no OneLake. Há suporte para permissões de nível SQL em tabelas, garantindo uma governança consistente em ferramentas como Power BI, notebooks e lakehouse.

• Modo de identidade delegado: fornece controle total por meio do SQL. Nesse modo, o ponto de extremidade de análise do SQL se conecta ao OneLake usando a identidade do workspace ou do proprietário do item, e a segurança é regida exclusivamente por permissões SQL definidas dentro do banco de dados. Esse modelo dá suporte a abordagens de segurança tradicionais, incluindo GRANT, REVOKE, funções personalizadas, segurança de Row-Level e máscara dinâmica de dados.

Cada modo dá suporte a modelos de governança diferentes. Entender suas implicações é essencial para escolher a abordagem certa em seu ambiente do Fabric.

Comparação entre os modos de acesso

Aqui está uma tabela de comparação clara e concisa focada em como e onde você define a segurança no modo de identidade do usuário versus o modo de identidade delegado, dividido por tipo de objeto e políticas de acesso a dados:

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

No modo de identidade do usuário, o ponto de extremidade de análise do SQL usa um mecanismo de autenticação de passagem para impor o acesso a dados. Quando um usuário se conecta ao ponto de extremidade de análise do SQL, sua identidade de ID do Entra é passada para o OneLake, que executa 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 quaisquer instruções GRANT ou REVOKE de nível SQL.

Esse modo permite gerenciar a segurança centralmente, garantindo a imposição consistente em todas as experiências do Fabric, incluindo Power BI, notebooks, lakehouse e ponto de extremidade de análise de SQL. Ele foi projetado para modelos de governança em que o acesso deve ser definido uma vez no OneLake e respeitado automaticamente em todos os lugares.

No modo de identidade do usuário:

• O acesso à tabela é regido inteiramente pela segurança do OneLake. Instruções SQL GRANT/REVOKE em tabelas são ignoradas.

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

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

• Não há suporte para operações de gravação no ponto de extremidade de análise do SQL. Todas as gravações devem ocorrer por meio da interface do usuário do Lakehouse e são regidas por funções de workspace (Administrador, Membro, Colaborador).

Comportamento da função do workspace

Os usuários com a função Administrador, Membro ou Colaborador no nível do workspace 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 RLS, CLS e OLS. Siga estes requisitos para garantir que a segurança do OneLake seja respeitada:

• Atribuir aos usuários a função Visualizador no workspace ou

• Compartilhe o ponto de extremidade de análise lakehouse ou SQL com usuários usando permissões somente leitura . Somente usuários com acesso somente leitura têm suas consultas filtradas de acordo com as funções de segurança do OneLake.

Precedência de função: o acesso mais permissivo vence

Se um usuário pertencer a várias funções do OneLake, a função mais permissiva definirá 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.

• A função de acesso mais ampla tem precedência. Esse comportamento garante que os usuários não sejam bloqueados involuntariamente, mas requer um design de função cuidadoso para evitar conflitos. É recomendável manter funções restritivas e permissivas mutuamente exclusivas ao impor controles de acesso em nível de linha ou coluna.

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

Sincronização de segurança entre o ponto de extremidade de análise do OneLake e do 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 em funções de segurança no OneLake e garante que essas alterações sejam refletidas no ponto de extremidade de análise do SQL.

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

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

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

• Garantir que os objetos de atalho (tabelas provenientes de outras casas de lago) sejam validados corretamente 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 do SQL para replicar o comportamento de segurança. Como a segurança é imposta centralmente:

• Você não pode definir RLS, CLS ou OLS diretamente usando T-SQL nesse modo.

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

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

Comportamento de atalhos com sincronização de segurança

A segurança do OneLake é imposta na fonte da verdade, portanto, a sincronização de segurança desabilita o encadeamento de propriedade para tabelas e exibiçõ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 usuários devem ter acesso válido naorigem do atalho (ponto de extremidade atual da análise do Lakehouse ou sql) e no destino em que os dados residem fisicamente.

• Se o usuário não tiver permissão em ambos os lados, as consultas falharão com um erro de acesso.

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

Esse design preserva a integridade de segurança entre os limites do Lakehouse, mas apresenta cenários em que falhas de acesso podem ocorrer se as funções entre Lakehouse não estiverem alinhadas.

Modo delegado na segurança do OneLake

No Modo de Identidade Delegada, o ponto de extremidade de análise do SQL usa o mesmo modelo de segurança que existe hoje no Microsoft Fabric. A segurança e as permissões são gerenciadas inteiramente na camada SQL, e as funções ou políticas de acesso do OneLake não são impostas para acesso no nível da tabela. Quando um usuário se conecta ao ponto de extremidade de análise do 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 estiver autorizada, o sistema continuará acessando os dados armazenados no OneLake.

• Esse acesso a dados é executado usando a identidade do proprietário do ponto de extremidade de análise lakehouse ou SQL , também conhecido como a conta de item.

Neste modelo:

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

• Supõe-se que toda a imposição de acesso seja tratada 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 esse é um padrão delegado, qualquer desalinhamento entre permissões SQL e acesso OneLake para o proprietário resulta em falhas de consulta. Esse modo fornece compatibilidade completa com:

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

• Segurança deRow-Level definida pelo SQL, segurançaColumn-Level e máscara dinâmica de dados

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

Como alterar o modo de acesso do OneLake

O modo de acesso determina como o acesso a dados é autenticado e imposto ao consultar o OneLake por meio do ponto de extremidade de análise do SQL. Você pode alternar entre o modo de identidade do usuário e o modo de identidade delegado usando as seguintes etapas:

1. Navegue até o workspace do Fabric e abra o lakehouse. No canto superior direito, alterne do lakehouse para o ponto de extremidade de análise do SQL.

2. Na navegação superior, acesse a guia Segurança e selecione um dos seguintes modos de acesso do OneLake:

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

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

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

Considerações ao alternar entre modos

Alternar para o modo de identidade do usuário

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

• As funções OneLake devem ser configuradas para que os usuários mantenham o acesso.

• Somente os usuários com permissões do Visualizador ou acesso somente leitura compartilhado serão regidos pela segurança do OneLake.

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

Alternar para o modo de identidade delegado

• As funções do OneLake e as políticas de segurança 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 acesso válido ao OneLake ou todas as consultas podem falhar.

Limitações

• Aplica-se somente aos leitores: o OneLake Security rege os usuários que acessam dados como Visualizadores. Os usuários em outras funções de workspace (Membro Administrador ou Colaborador) ignoram a Segurança do OneLake e mantêm acesso total.

• Os objetos SQL não herdam a propriedade: os atalhos são exibidos no ponto de extremidade de análise do SQL como tabelas. Ao acessar essas tabelas, diretamente ou por meio de exibições, procedimentos armazenados e outros objetos SQL derivados não têm propriedade no nível do objeto; todas as permissões são verificadas em runtime para evitar o bypass de segurança.

• Alterações de atalho disparam o tempo de inatividade de validação: quando um destino de atalho é alterado (por exemplo, renomear, atualização de 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 um processo interno diferente pode 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. Alternar entre os modos de segurança (Identidade do Usuário vs. Delegado) pode exigir tempo para 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 workspace. Você precisa compartilhar o item de origem ou o usuário deve ser membro da função de workspace do Visualizador. Observe que a mesma ID de objeto deve estar em ambos os lugares. Um grupo e um membro desse grupo não contam como correspondência.

• O acesso mais permissivo prevalece: quando os usuários pertencem a vários grupos ou funções, a permissão efetiva mais permissiva é respeitada Exemplo: se um usuário tiver DENY por meio de uma função e GRANT por meio de outra, o GRANT terá precedência.

• Limitações de modo delegado: no modo Delegado, a sincronização de metadados em tabelas de atalho poderá falhar se o item de origem tiver políticas de Segurança do OneLake que não concedem acesso completo à tabela ao proprietário do item.

• Comportamento DENY: quando várias funções se aplicam a uma única tabela de atalho, a interseção de permissões segue a semântica do SQL Server: DENY substitui GRANT. Isso 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 origem da tabela foi excluída.

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

    • Algumas expressões para filtragem RLS não têm suporte no OneLake e podem permitir acesso a dados não autorizados.

    • Remover a coluna usada na expressão de 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, só damos suporte a tabelas de expressão única. RLS dinâmico e RLS de várias tabelas não têm suporte no momento.

  • limitações de CLS (segurança do Column-Level)

    • O 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 CLS é inválido, a sincronização de metadados é bloqueada até que a regra CLS seja corrigida no painel segurança do OneLake.

  • Falha de 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.

• As renomeações de tabela não preservam as políticas de segurança: se as funções de Segurança do OneLake (OLS) forem definidas no nível do esquema, essas funções permanecerão em vigor apenas enquanto o nome da tabela não for alterado. Renomear a tabela interrompe a associação e as políticas de segurança não serão migradas automaticamente. Isso pode resultar em exposição de dados não intencional 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 endpoint de análise do SQL com o prefixo OLS_.

• Não há suporte para alterações de usuário nas funções de 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 da Lakehouse deve ser membro das funções de papel de trabalho de administrador, membro ou colaborador; caso contrário, a segurança não será aplicada ao endpoint de análise do SQL.

• O proprietário da lakehouse 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 controle de acesso de segurança do OneLake