Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Com a segurança do OneLake, o Microsoft Fabric está expandindo a forma como as organizações podem gerenciar e impor o acesso a dados em 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 ponto de extremidade de análise SQL
Ao usar o ponto de extremidade de análise SQL, o modo de acesso selecionado determina como a segurança de dados é imposta. O Fabric suporta 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 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 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 se conecta 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 suas implicações é essencial para escolher a abordagem certa em seu ambiente de malha.
Comparação entre 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 delegada, dividida por tipo de objeto e políticas de acesso a dados:
| Alvo de segurança | Modo de identidade do usuário | Modo de identidade delegada |
|---|---|---|
| Tables | O acesso é controlado por funções de segurança OneLake. SQL GRANT/REVOKE não é permitido. |
Controle total usando SQL GRANT/REVOKE. |
| Views | Use SQL GRANT/REVOKE para atribuir permissões. | Use SQL GRANT/REVOKE para atribuir permissões. |
| Procedimentos armazenados | Use SQL GRANT EXECUTE para atribuir permissões. | Use SQL GRANT EXECUTE para atribuir permissões. |
| Funções | Use SQL GRANT EXECUTE para atribuir permissões. | Use SQL GRANT EXECUTE para atribuir permissões. |
| SegurançaRow-Level (RLS) | Definido na interface do usuário do OneLake como parte das funções de segurança do OneLake. | Definido usando SQL CREATE SECURITY POLICY. |
| SegurançaColumn-Level (CLS) | Definido na interface do usuário do OneLake como parte das funções de segurança do OneLake. | Definido usando SQL GRANT SELECT com lista de colunas. |
| Mascaramento dinâmico de dados (DDM) | Não suportado na segurança OneLake. | Definido usando SQL ALTER TABLE com MASKED opção. |
Modo de identidade do usuário na segurança do OneLake
No modo de identidade do usuário, o ponto de extremidade da análise SQL usa um mecanismo de autenticação de passagem para impor o acesso aos dados. Quando um usuário se conecta ao ponto de extremidade de análise 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 nenhuma instrução GRANT ou REVOKE de nível SQL.
Esse modo permite gerenciar a segurança centralmente, garantindo uma aplicação consistente em todas as experiências de malha, incluindo Power BI, blocos de anotações, lakehouse e ponto de extremidade de análise SQL. Ele foi projetado para modelos de governança em que o acesso deve ser definido uma vez no OneLake e automaticamente respeitado em todos os lugares.
No modo de identidade do usuário:
O acesso à tabela é regido inteiramente pela segurança 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 gravações devem ocorrer por meio da interface do usuário do Lakehouse e são regidas por funções de espaço de trabalho (Administrador, Membro, Colaborador).
Importante
O ponto de extremidade do SQL Analytics requer um mapeamento um-para-um entre as permissões de item e os membros numa função de segurança do OneLake para sincronizar corretamente. Se conceder acesso de identidade a uma função de segurança do OneLake, essa mesma identidade também precisará ter permissão de leitura Fabric para o lakehouse. Por exemplo, se um utilizador atribui "user123@microsoft.com" a uma função de segurança OneLake, então "user123@microsoft.com" também deve ser atribuído a esse lakehouse.
Comportamento da função de 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 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ções: o acesso mais permissivo vence
Se um usuário pertence a várias funções OneLake, a função mais permissiva define seu acesso efetivo. Por exemplo:
Se uma função conceder acesso total a uma tabela e outra aplicar a RLS para restringir linhas, a RLS não será imposta.
O papel de acesso mais amplo 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. Recomenda-se 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 segurança do OneLake.
Sincronização de segurança entre o OneLake e o ponto de extremidade 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 ponto de extremidade da análise 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
| Scenario | Comportamento no modo de identidade do usuário | Comportamento no modo delegado | Ação corretiva | Observações |
|---|---|---|---|---|
| A política RLS faz referência a uma coluna excluída ou renomeada | Erro: *A política de segurança em nível de linha faz referência a uma coluna que não existe mais.*O banco de dados entra no estado de erro até que a diretiva seja corrigida. | Erro: Nome <da coluna inválido nome> da coluna | Atualize ou remova uma ou mais funções afetadas ou restaure a coluna ausente. | A atualização precisará ser feita na casa do lago onde a função foi criada. |
| A política CLS faz referência a uma coluna excluída ou renomeada | Erro: *A política de segurança em nível de coluna faz referência a uma coluna que não existe mais.*O banco de dados entra no estado de erro até que a diretiva seja corrigida. | Erro: Nome <da coluna inválido nome> da coluna | Atualize ou remova uma ou mais funções afetadas ou restaure a coluna ausente. | A atualização precisará ser feita na casa do lago onde a função foi criada. |
| A política RLS/CLS faz referência a uma tabela excluída ou renomeada | Erro: A política de segurança faz referência a uma tabela que não existe mais. | Nenhum erro apareceu; A consulta falhará silenciosamente se a tabela estiver ausente. | Atualize ou remova uma ou mais funções afetadas ou restaure a tabela ausente. | A atualização precisará ser feita na casa do lago onde a função foi criada. |
| A política DDM (Dynamic Data Masking) faz referência a uma coluna excluída ou renomeada | DDM não suportado pelo OneLake Security, deve ser implementado através de SQL. | Erro: Nome <da coluna inválido nome> da coluna | Atualize ou remova uma ou mais regras DDM afetadas ou restaure a coluna ausente. | Atualize a política DDM no ponto de extremidade do SQL Analytics. |
| Erro do sistema (falha inesperada) | Erro: Ocorreu um erro de sistema inesperado. Tente novamente ou entre em contato com o suporte. | Erro: Ocorreu um erro interno ao aplicar alterações de tabela ao SQL. | Operação de repetição; se o problema persistir, contacte o Suporte da Microsoft. | N/A |
| O usuário não tem permissão sobre o artefato | Erro: O usuário não tem permissão no artefato | Erro: O usuário não tem permissão no artefato | Forneça ao usuário a permissão objectID {objectID} para o artefato. | A ID do objeto deve ser uma correspondência exata entre o membro da função de segurança OneLake e as permissões do item Fabric. Se um grupo for adicionado à associação de função, esse mesmo grupo deverá receber a permissão de Leitura de Malha. Adicionar um membro desse grupo ao item não conta como uma correspondência direta. |
| A entidade principal do utilizador não é suportada. | Erro: O principal de utilizador não é suportado. | Erro: Principal de usuário não é suportado. | Remova o usuário {username} da função DefaultReader | Este erro ocorre se o usuário não for mais um ID do Entra válido, como se o usuário tiver saído da sua organização ou tiver sido excluído. Remova-os da função para resolver esse erro. |
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 do Lakehouse ou do SQL Analytics) e no destino onde 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, certifique-se de que as atribuições de função estejam configuradas corretamente em ambas as extremidades da relação de atalho.
Esse design preserva a integridade da segurança através dos 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 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 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 continuará a acessar os dados armazenados no OneLake.
Esse acesso a dados é realizado usando a identidade do proprietário do ponto de extremidade Lakehouse ou do SQL Analytics — também conhecido como conta do item.
Neste modelo:
O usuário conectado não é passado para o OneLake.
Presume-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 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 deRow-Level definida por SQL, segurançaColumn-Level e mascaramento dinâmico de dados
Ferramentas e práticas T-SQL existentes usadas por DBAs ou aplicativos
Como alterar o modo de acesso OneLake
O modo de acesso determina como o acesso aos dados é autenticado e imposto ao consultar o OneLake por meio do ponto de extremidade 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:
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.
Na navegação superior, vá para a guia Segurança e selecione um dos seguintes modos de acesso 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.
Um pop-up é iniciado 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.
As funções OneLake devem ser configuradas para que os usuários mantenham o acesso.
Somente usuários com permissões de Visualizador ou acesso compartilhado somente leitura serão regidos pela segurança do 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 acesso OneLake válido, ou todas as consultas podem falhar.
Limitações
Aplica-se apenas aos leitores: o OneLake Security rege os usuários que acessam dados como Visualizadores. Os usuários em outras funções de espaço de trabalho (Administrador, Membro ou Colaborador) ignoram 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 usuário deve ser membro da função de espaço de trabalho Visualizador. 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 usuários pertencem a vários grupos ou funções, a permissão efetiva mais permissiva é honrada Exemplo: Se um usuário tiver DENY através de uma função e GRANT através de outra, o GRANT terá precedência.
Limitações do modo delegado: no modo delegado, a sincronização de metadados em tabelas de atalho pode falhar se o item de origem tiver políticas de segurança do OneLake que não concedam acesso total à tabela ao proprietário do item.
Comportamento DENI: 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 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 podem permitir acesso não autorizado a dados.
Soltar a coluna usada na expressão de filtro invalida a RLS e a Sincronização de Metadados ficará obsoleta até que a RLS seja corrigida 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 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.
As renomeações de tabela não preservam as políticas de segurança: se as funções do OneLake Security (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 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.