Permissões de atalhos do Microsoft Fabric: regras de segurança internas e externas

By Mirko Peters · 2026-10-30

Saiba como funcionam as permissões dos atalhos do Microsoft Fabric, comparando a propagação da identidade do usuário em atalhos internos com as regras de segurança das conexões armazenadas em atalhos externos.

Automatically translated with AI from the original post. Read the English original

As permissões dos atalhos do Microsoft Fabric determinam como os usuários acessam dados entre workspaces e multicloud sem copiar arquivos. Os atalhos internos dependem da propagação da identidade no nível do usuário, enquanto as fontes de nuvem externa usam identidades de conexões armazenadas. Entender esses limites de segurança evita a exposição não autorizada de dados e resolve erros de consulta que costumam atrapalhar o trabalho.

Principais conclusões

• Os atalhos internos propagam a identidade do usuário que faz a consulta, exigindo direitos de acesso diretos no caminho de destino.
• Os atalhos de nuvem externa usam credenciais de conexões armazenadas, concedendo acesso a qualquer pessoa que possa ler o lakehouse.
• Quando os níveis de permissão entram em conflito entre o caminho do atalho e o caminho de destino, a regra de segurança mais restritiva sempre prevalece.
• Atalhos graváveis representam um risco grave de exclusões de dados em cascata se as permissões do destino estiverem mal configuradas.
• Planejar os seus limites de segurança evita falhas de acesso inesperadas ao escalar arquiteturas multicloud.

Como funcionam as permissões dos atalhos do Microsoft Fabric

Quando você implementa ponteiros entre diferentes fontes de dados no OneLake, a segurança raramente é uma configuração do tipo "configure e esqueça". Diferentemente dos modelos tradicionais de data warehouse, em que as permissões são centralizadas e aplicadas de forma uniforme às tabelas clonadas, os atalhos do Fabric introduzem um problema de identidade dividida. Há um caminho de atalho, onde o usuário inicia a consulta, e um caminho de destino, onde estão os dados físicos. O Fabric avalia os dois pontos antes de retornar uma única linha de dados, o que torna a arquitetura de segurança um pré-requisito crítico de projeto para os administradores de nuvem.

O princípio central da segurança do Fabric é o de privilégio mínimo, mas os atalhos flexibilizam as regras tradicionais de acesso a dados. Como os dados não se movem quando um atalho é criado, as permissões associadas à conta de armazenamento subjacente, ao bucket externo do Amazon S3 ou ao lakehouse irmão precisam ser mapeadas com cuidado. Se um usuário tem acesso de leitura ao workspace que contém o atalho, mas não tem acesso ao contêiner de origem, a consulta falhará. Por outro lado, conceder permissões excessivamente amplas a uma identidade de conexão armazenada pode expor, sem querer, arquivos externos sensíveis a usuários avançados não autorizados.

Atalhos internos e propagação da identidade do usuário

Os atalhos internos — que apontam de um item do Fabric para outro, como um lakehouse em um workspace de vendas apontando para uma tabela compartilhada de clientes — funcionam com a sua identidade exata do Entra ID. Ao consultar um atalho interno, o Fabric verifica se a sua conta tem permissões de leitura explícitas no workspace e no item de destino. Se você não tiver permissão para visualizar as tabelas de origem, o atalho retornará um erro.

Esse comportamento foi projetado para espelhar a governança de acesso tradicional. Ele impede que usuários avançados contornem os limites dos workspaces simplesmente criando atalhos para datasets restritos. No entanto, isso também significa que os criadores de relatórios precisam ter acesso adequado provisionado em vários workspaces, o que aumenta a sobrecarga administrativa de gerenciar equipes de análise colaborativa.

Atalhos externos e identidades de conexão armazenadas

Atalhos externos mudam completamente a dinâmica de segurança. Quando você aponta um lakehouse do Fabric para uma conta do Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage ou um local de rede on-premises por meio de um gateway de dados, a propagação da identidade do usuário para na fronteira do Fabric. Em vez disso, os atalhos externos se autenticam usando uma identidade de conexão armazenada.

Essa diferença operacional tem implicações de segurança enormes. Qualquer pessoa com acesso de leitura ao lakehouse do Fabric que contém o atalho externo pode consultar a fonte de dados subjacente por meio dele, independentemente de ter credenciais diretas para o bucket da nuvem externa. Os administradores devem tratar os lakehouses com atalhos externos como zonas de alta sensibilidade, restringindo rigorosamente as funções nos workspaces para evitar a exfiltração não autorizada de dados.

A regra do mais restritivo prevalece

Ao solucionar erros de acesso no Microsoft Fabric, os administradores frequentemente se deparam com a regra que governa as permissões de atalhos: a mais restritiva entre as duas permissões prevalece.

Avaliar essa regra exige olhar para as duas extremidades do ponteiro:

• Permissões do caminho do atalho: As atribuições de função (Administrador, Membro, Colaborador, Leitor) no workspace e no lakehouse onde o atalho está localizado.
• Permissões do caminho de destino: As listas de controle de acesso (ACLs), políticas IAM ou permissões de banco de dados aplicadas diretamente aos arquivos ou tabelas de origem.

Se um usuário é Colaborador no workspace que hospeda o atalho, mas tem apenas permissão de Leitor na conta de armazenamento de destino, ele só conseguirá ler os dados. Por outro lado, se um usuário tem direitos de administrador completos no dataset de origem, mas sua função no workspace é restrita a Leitor, ele não pode modificar nem gerenciar a configuração do atalho. Essa aplicação em duas camadas garante que nenhuma configuração incorreta isolada derrube completamente o perímetro de segurança da organização, mas exige documentação cuidadosa ao coordenar entre departamentos de TI separados.

Riscos de atalhos graváveis e exclusões em cascata

As permissões de segurança não definem apenas quem pode ler os dados; elas também determinam o que os usuários podem destruir. Uma das armadilhas mais perigosas para administradores júnior envolve atalhos graváveis combinados com configurações de identidade excessivamente permissivas.

Os atalhos do Fabric não executam exclusões em cascata nos dados subjacentes se você excluir o próprio objeto de atalho: seus dados de destino permanecem totalmente seguros. No entanto, se um atalho for gravável e um usuário tiver permissão de exclusão no caminho de destino, excluir arquivos ou pastas pelo caminho do atalho apagará permanentemente os dados na origem. O atalho funciona como uma porta direta para o sistema de armazenamento de destino, e um script de limpeza equivocado ou uma ação acidental de um usuário pode derrubar paredes estruturais mais rápido do que os pipelines de dados tradicionais jamais conseguiriam.

Conclusão

Dominar as permissões de atalhos do Microsoft Fabric exige uma mudança fundamental na forma como você pensa sobre acesso e governança de dados. Ao equilibrar a propagação da identidade do usuário para cargas de trabalho internas com credenciais armazenadas e rigorosamente controladas para fontes multinuvem, você pode construir um ambiente analítico responsivo e de cópia zero sem comprometer a segurança. Para explorar estratégias arquiteturais mais amplas, formatos de dados e trade-offs, não deixe de ouvir o episódio completo para uma análise detalhada do gerenciamento moderno de dados em nuvem.

Perguntas frequentes

Os atalhos do Microsoft Fabric herdam as permissões do usuário automaticamente?

Atalhos internos usam sua identidade pessoal do Entra ID, o que significa que você precisa ter acesso de leitura explícito tanto ao workspace do atalho quanto ao workspace de destino. Já os atalhos externos usam uma identidade de conexão armazenada, permitindo que qualquer pessoa com acesso ao lakehouse leia os dados externos.

O que acontece com os dados se eu excluir um atalho do Microsoft Fabric?

Excluir o próprio objeto de atalho não apaga os dados no caminho de destino. Os arquivos ou tabelas físicos permanecem totalmente seguros, a menos que o atalho tenha sido configurado como gravável e o usuário tenha excluído arquivos explicitamente pelo caminho do atalho, com permissões suficientes no destino.

Como os atalhos de nuvem externa lidam com a autenticação para AWS S3 ou Google Cloud Storage?

Os atalhos de nuvem externa se autenticam usando uma conexão armazenada, configurada durante a configuração, em vez de repassar as credenciais individuais de cada usuário. Por isso, as listas de controle de acesso do workspace funcionam como a principal barreira de segurança para usuários que consultam dados multinuvem externos.

O que significa a regra de segurança "stricter-wins" no Fabric?

A regra "stricter-wins" determina que, na avaliação de acesso, o Fabric aplica o conjunto de permissões mais restritivo encontrado entre o caminho do atalho e o caminho de destino. Se qualquer um dos locais negar o acesso ou restringir recursos, essas limitações se aplicam ao usuário final.