Implementação de Row-Level Security Dinâmica no Power BI e no Microsoft Fabric: Arquitetura, Padrões DAX e Governança de Nível Empresarial

By Mirko Peters · 2025-11-21 · Updated 2025-11-26

Implemente row-level security dinâmica no Power BI e no Microsoft Fabric para controlar o acesso dos usuários aos dados, garantir conformidade e se adaptar às mudanças na organização.

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

Você deve pensar na Row-Level Security Dinâmica como um sistema que pode mudar. Ela cresce e se transforma junto com a sua organização. O design do modelo de dados, as expressões DAX, a identidade do usuário e a governança ajudam a definir como a segurança funciona no Power BI e no Microsoft Fabric. Se você configurar isso da maneira certa, poderá decidir quem tem acesso a determinados dados.

Principais conclusões

• A Row-Level Security Dinâmica se ajusta às necessidades da sua empresa. Ela permite escolher quem pode ver determinados dados, verificando a identidade de cada usuário.

• Use USERPRINCIPALNAME() para a segurança na nuvem. Essa função permite que os usuários vejam apenas os próprios dados e ajuda a manter suas informações protegidas.

• Revise com frequência a configuração de segurança e os grupos de usuários. Isso impede que pessoas vejam dados que não deveriam ver e ajuda a manter seus dados protegidos.

• Crie tabelas de segurança claras para gerenciar as permissões dos usuários. Isso ajuda você a controlar quem pode ver o quê à medida que a empresa cresce.

• Teste suas regras de segurança na nuvem com usuários reais. Isso garante que seus dados estejam protegidos e que os usuários vejam apenas o que têm permissão para ver.

Repensando os sistemas de Row-Level Security

Segurança como um sistema orientado pelo modelo

A row-level security é um sistema que conecta diferentes partes da sua plataforma de análise. Ao criar o modelo de dados, você já começa a construir a segurança dos dados. A forma como você configura as tabelas, as conecta e cria as funções altera a maneira como as pessoas veem os dados. Se a sua empresa crescer ou novas equipes entrarem, será preciso atualizar as regras de segurança. A row-level security não é algo que você configura uma vez e esquece. Ela muda conforme o seu negócio muda e atende a novas necessidades.

Dica: revise o seu modelo de dados com frequência. Um bom modelo facilita a segurança e ajuda você a evitar erros.

O seu modelo deve ter relações claras e tabelas de segurança específicas. Isso permite controlar quem vê determinados dados e mantém os dados privados protegidos. A row-level security dinâmica pode associar o que cada usuário vê ao seu grupo ou à sua função no Fabric. Assim, você consegue alterar as permissões rapidamente quando a empresa muda.

Row-Level Security estática vs. dinâmica

Existem duas formas principais de configurar a segurança dos dados: row-level security estática e dinâmica. A segurança estática usa regras fixas. Você cria funções e filtros para cada grupo. Isso funciona bem para equipes pequenas ou quando o acesso não muda com frequência. A row-level security dinâmica usa a identidade do usuário conectado e tabelas de mapeamento. Ela verifica o usuário e altera imediatamente os dados que ele vê. É a melhor opção para grandes empresas com muitos usuários e regras em constante mudança.

Aqui está uma tabela com as diferenças:

A row-level security dinâmica oferece mais formas de controlar o acesso. Ela usa recursos como USERPRINCIPALNAME() e tabelas de mapeamento para associar cada usuário aos dados corretos. A segurança estática é simples, mas não funciona bem quando a empresa cresce ou muda muito.

• A row-level security estática usa regras fixas para limitar os dados.

• A row-level security dinâmica altera o que cada usuário vê com base na sua identidade.

• A segurança dinâmica é a melhor opção para grandes empresas com muitas regras.

Para manter seus dados protegidos, escolha a abordagem mais adequada às suas necessidades. Um bom planejamento e um modelo sólido ajudam a proteger dados privados e a manter suas análises seguras.

Padrões de Row-Level Security dinâmica no Fabric

Funções DAX: USERPRINCIPALNAME() vs. USERNAME()

É importante entender como a identidade funciona no Fabric. Duas funções principais ajudam a configurar a row-level security: USERPRINCIPALNAME() e USERNAME(). Ambas identificam quem está visualizando o relatório. USERPRINCIPALNAME() retorna o e-mail do usuário na nuvem. USERNAME() normalmente retorna o nome de uma conta local, principalmente no Power BI Desktop. Se você usar USERNAME() na nuvem, ele pode não funcionar corretamente, o que pode tornar seus dados menos seguros.

Dica: use sempre USERPRINCIPALNAME() para segurança em nível de linha dinâmica no Fabric. Essa função corresponde ao e-mail de nuvem do usuário e mantém seus dados protegidos.

Se você usar a função errada, os usuários poderiam ver dados que não deveriam. Você precisa testar sua segurança na nuvem, e não apenas no Desktop.

Padrões e antipadrões seguros de DAX

Você quer que seus dados permaneçam seguros. Precisa de padrões DAX sólidos para segurança em nível de linha dinâmica. A melhor forma é usar tabelas de mapeamento e regras dinâmicas. Isso permite controlar quem pode ver o quê.

• Filtros de linha ajudam a limitar o que os usuários podem ver. Você pode bloquear dados por região, departamento ou conta.

• Máscaras de coluna permitem ocultar ou alterar dados com base em quem é o usuário.

Um bom padrão DAX usa uma pesquisa para associar os usuários ao seu grupo. Isso funciona bem para empresas com muitos grupos. Veja um bom exemplo:

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

Esse padrão verifica o e-mail do usuário e encontra o grupo dele. Você pode usar isso para mostrar apenas os dados certos. Essa abordagem é melhor do que apenas comparar e-mails. Ela funciona bem à medida que a empresa cresce e mantém seus dados protegidos.

Nota: não coloque e-mails fixos no código nem use colunas calculadas para controle de acesso. Essas abordagens podem quebrar se os usuários mudarem ou se a empresa crescer.

Alguns padrões ruins podem causar vazamentos de dados:

• Usar USERNAME() na nuvem.

• Colocar e-mails ou domínios de usuários fixos no código.

• Colocar a lógica de segurança em colunas calculadas.

Você deve sempre usar regras dinâmicas e tabelas de mapeamento. Isso mantém seu modelo de dados simples e seus dados protegidos.

Hierarquias e a função PATH()

Às vezes você precisa de segurança para gerentes, equipes ou departamentos. Hierarquias ajudam a fazer isso. A função PATH() no DAX permite criar vínculos pai-filho. Você pode usar isso para controlar quem vê o quê em cada nível.

Por exemplo, você pode criar uma tabela com os IDs de funcionários e de gerentes. A PATH() monta uma cadeia de cada colaborador até o seu chefe. Depois, use DAX para filtrar os dados de cada nível.

PATH(Employee[EmployeeID], Employee[ManagerID])

Essa função ajuda a configurar segurança em nível de linha dinâmica para grandes empresas. Você pode permitir que gerentes vejam os dados de suas equipes. Também pode impedir que colaboradores comuns vejam informações demais.

Dica: use PATH() para segurança com hierarquias. Isso torna seu modelo de dados flexível e mantém seus dados protegidos.

Você pode usar filtros de linha, máscaras de coluna e funções de hierarquia em conjunto. Isso ajuda a proteger dados privados e a controlar o acesso à medida que a empresa cresce.

Arquitetura de funções e relacionamentos

Design de tabelas de segurança

Você precisa criar tabelas de segurança para a segurança em nível de linha dinâmica. Essas tabelas mostram quais usuários podem ver quais dados. Use colunas para e-mail do usuário, grupo e nível de acesso. Essa estrutura ajuda a manter os dados seguros à medida que a empresa cresce.
Ao criar funções, mantenha funções restritas e funções abertas separadas. Se uma função permitir que alguém veja tudo, outras funções com segurança em nível de linha podem não funcionar corretamente. Impeça que as funções entrem em conflito entre si para manter os dados seguros.

• Crie tabelas de segurança com colunas claras para usuário e permissões.

• Mantenha as funções separadas para que não se sobreponham e causem problemas.

• Revise suas tabelas de segurança com frequência para acompanhar as mudanças.

Relacionamentos no modelo de dados

A forma como você constrói o modelo de dados muda a forma como controla o acesso. Use relacionamentos unidirecionais entre as tabelas. Isso deixa o modelo simples e ajuda a evitar erros.
É melhor usar tabelas de segurança específicas do que colocar permissões nas tabelas de fatos. Você pode vincular a tabela de segurança a outras tabelas, como departamento ou região. Assim, é possível filtrar os dados de cada usuário ou grupo.

Dica: use tabelas ponte para vincular usuários aos dados. Isso ajuda a segurança em nível de linha dinâmica a funcionar e mantém seus dados protegidos.

Granularidade de funções: funções pequenas x funções grandes

Você precisa decidir o nível de detalhe dos seus papéis. Papéis pequenos dão mais controle. Você pode conceder acesso por função ou por grupo. Papéis grandes abrangem mais pessoas, mas podem ser arriscados se as coisas mudarem.
Verifique com frequência quem tem cada papel. Isso mantém seus dados seguros e permite fazer ajustes quando necessário.
Escolha papéis pequenos para mais controle e atualizações mais fáceis. Papéis grandes podem funcionar em grupos simples, mas podem causar problemas em empresas grandes.

Atribuições de usuários e grupos no Fabric

Grupos do Azure AD versus indivíduos

Você concede acesso no Fabric colocando usuários em grupos do Azure AD. Assim, pode controlar os dados de muitas pessoas de uma só vez. É mais seguro usar grupos do que adicionar cada pessoa individualmente. Os grupos ajudam você a gerenciar o sistema com menos trabalho. Quando sua equipe muda, você pode atualizar os grupos rapidamente. Vincular grupos a papéis facilita a modelagem de dados. Suas regras de segurança em nível de linha ficam claras e simples.

Dica: use grupos do Azure AD para controle de acesso. Isso ajuda a cometer menos erros e economiza tempo.

Grupos sobrepostos e acesso oculto

Você precisa ficar atento a grupos sobrepostos. Às vezes, um usuário está em mais de um grupo. Isso pode permitir que ele veja dados que não deveria ver. O acesso oculto ocorre quando esse erro faz com que usuários vejam dados extras. Você deve verificar as listas de grupos com frequência para evitar isso. Use tabelas para acompanhar quais usuários estão em cada grupo. A boa modelagem de dados ajuda a identificar problemas cedo. Remova usuários de grupos que não precisam mais para manter os dados seguros.

Nota: o acesso oculto pode expor dados privados. Corrija as sobreposições de grupos para manter seu sistema seguro.

Revisões de acesso programadas

Você deve planejar revisões de acesso regulares. Verifique periodicamente quem está em cada grupo. Peça aos proprietários dos grupos que confirmem quem deve ter acesso. Isso mantém sua segurança dinâmica em nível de linha funcionando à medida que a empresa cresce. Use as ferramentas do Fabric para ajudar nessas verificações. Remova usuários antigos para tornar seus dados mais seguros. Isso mantém seu sistema de analytics organizado e seguro. Torne as revisões de acesso uma parte normal do seu trabalho de business intelligence.

• Escolha datas para revisar todos os grupos.

• Use as ferramentas do Fabric para ajudar a verificar os grupos.

• Peça aos proprietários que confirmem quem está em cada grupo.

Alerta: revisões regulares ajudam a identificar erros antes que eles causem problemas.

Resolução de identidade: Desktop versus Fabric

Funções de identidade e diferenças na nuvem

É importante entender como a identidade funciona no Power BI Desktop e no Microsoft Fabric. No Power BI Desktop, USERNAME() normalmente mostra o nome do seu computador. No Microsoft Fabric, USERPRINCIPALNAME() retorna seu endereço de e-mail na nuvem. Essa diferença é importante para manter os dados seguros. Se você usar USERNAME() na nuvem, as pessoas erradas podem ver os dados. Sempre use USERPRINCIPALNAME() para relatórios na nuvem. Isso ajuda a manter seus dados seguros e alinhado ao sistema de identidade da sua empresa.

Dica: teste suas regras de segurança em nível de linha na nuvem. Os testes no Desktop não mostram o acesso real dos usuários.

Proprietário do conjunto de dados e configurações do locatário

Você precisa saber quem é o proprietário do seu conjunto de dados. O proprietário pode alterar as configurações de atualização e afetar quem vê os dados. Se você trocar o proprietário, pode alterar quem consegue ver dados privados. As configurações do locatário também são importantes. Essas configurações definem como as identidades funcionam na sua empresa. Verifique as configurações do locatário antes de publicar os relatórios. Certifique-se de que seu modelo de dados esteja alinhado às regras de segurança da empresa.

Causas comuns de vazamentos de RLS

Você pode perder o controle da segurança em nível de linha se não testar na nuvem. Às vezes, os usuários veem mais dados do que deveriam. Isso pode acontecer se você usar a função de identidade errada ou esquecer de atualizar as associações de grupos. Vazamentos também podem ocorrer se você alterar seu modelo de dados sem verificar as tabelas de segurança. Sempre revise a configuração de segurança dos dados após alterações. Use testes na nuvem e auditorias regulares para identificar problemas cedo.

Alerta: vazamentos de segurança de dados podem expor informações privadas. Revise sua configuração com frequência para manter sua organização segura.

Testes, auditoria e governança

Testes de RLS baseados na nuvem

Você deve testar a segurança em nível de linha na nuvem. Isso garante que seus dados estejam protegidos para usuários reais. A ferramenta “View As” no Desktop mostra apenas uma prévia. Ela não mostra como as regras funcionam no Microsoft Fabric. Depois de publicar seu relatório, teste com usuários e grupos reais. Assim você consegue ver o que cada pessoa pode visualizar. Use contas de teste para verificar se os usuários veem apenas os seus dados. Sempre teste novamente depois de alterar funções ou atualizar seu modelo. Testes na nuvem ajudam a identificar problemas antes que eles afetem o seu negócio.

Dica: sempre teste com usuários reais na nuvem, e não apenas no Desktop. Isso mantém a segurança dos seus dados sólida.

Automação para auditorias e revisões

Você pode usar automação para facilitar auditorias e revisões no Fabric. A automação verifica permissões de workspaces, fluxos de dados e rótulos de confidencialidade em uma programação. O Microsoft Purview oferece painéis para acompanhar as regras em toda a plataforma. Você pode usar logs de atividade e as APIs de administração para encontrar problemas de conformidade. A automação ajuda você a encontrar problemas cedo e economiza tempo. Auditores podem ver o caminho completo das colunas sensíveis, do início até o relatório. Isso torna as revisões mais rápidas e mais precisas. A automação também facilita e barateia o cumprimento de regras como GDPR e HIPAA.

• Configure verificações automáticas de permissões e fluxos de dados.

• Use painéis para acompanhar alterações nas regras de segurança.

• Analise os logs de atividade para encontrar problemas rapidamente.

Documentação e gerenciamento de mudanças

Você precisa de bons registros para manter seu sistema de segurança de dados claro. Documente suas regras de segurança, listas de grupos e alterações de funções. Atualize suas anotações sempre que mudar o modelo ou adicionar novos usuários. Registros claros ajudam você a acompanhar quem pode ver quais dados. Eles também ajudam novos membros da equipe a entender o sistema. O gerenciamento de mudanças significa verificar e aprovar atualizações antes que entrem em produção. Isso mantém sua segurança em nível de linha protegida à medida que a empresa cresce.

Alerta: mantenha seus registros atualizados. Isso protege seus dados e ajuda a resolver problemas rapidamente.

Você deve pensar na segurança em nível de linha como algo que muda à medida que seus dados e sua empresa crescem. Uma configuração sólida ajuda a manter as informações privadas protegidas. Usar bons padrões de DAX e gerenciar bem a identidade dos usuários protege seus dados. Verificar sua segurança e registrar as alterações ajuda a identificar problemas cedo. Se você planejar com antecedência, poderá controlar quem vê os dados e manter sua análise protegida.

• Verifique sua configuração de segurança com frequência.

• Use regras que evoluem para proteger melhor os dados.

• Coloque sempre a privacidade em primeiro lugar.

Perguntas frequentes

O que é segurança dinâmica em nível de linha no Power BI e no Fabric?

A segurança dinâmica em nível de linha permite controlar o acesso aos dados com base em quem está visualizando o relatório. Você usa funções DAX e tabelas de mapeamento para associar os usuários aos dados corretos.

Por que você deve usar USERPRINCIPALNAME() em vez de USERNAME()?

USERPRINCIPALNAME() retorna o e-mail do usuário na nuvem. Isso funciona melhor no Power BI e no Fabric. USERNAME() pode retornar um nome local, o que pode causar problemas de segurança na nuvem.

Como os grupos do Azure AD ajudam na segurança?

Os grupos do Azure AD permitem gerenciar o acesso de muitos usuários de uma só vez. Você adiciona usuários aos grupos e atribui funções. Isso torna sua configuração de segurança mais fácil e mais segura.

O que é uma tabela de segurança e por que você precisa dela?

Uma tabela de segurança lista usuários, grupos e permissões. Você a usa para controlar quem pode ver determinados dados. Isso ajuda a manter seus dados protegidos à medida que a empresa cresce.

Com que frequência você deve testar a segurança em nível de linha na nuvem?

Você deve testar a segurança em nível de linha sempre que alterar funções, grupos ou seu modelo de dados. Os testes na nuvem mostram o que os usuários reais podem ver e ajudam a identificar problemas cedo.