Segurança em nível de linha no Power BI: acesso a dados multilocatários

A segurança em nível de linha (RLS) é o mecanismo que garante que cada usuário veja apenas os dados que está autorizado a acessar. Em um ambiente multilocatário ou multidepartamental, o RLS não é opcional – é a diferença entre uma plataforma de análise governada e uma violação de dados esperando para acontecer. No entanto, a própria telemetria de utilização da Microsoft sugere que menos de 30% das organizações com Power BI Premium implementaram RLS nos seus conjuntos de dados de produção.

A razão não é que o RLS seja conceitualmente difícil. O motivo é que os detalhes da implementação são diferenciados, o processo de teste é manual e a interação entre o RLS e outros recursos do Power BI (DirectQuery, modelos compostos, incorporação, agregações) cria casos extremos que pegam as equipes desprevenidas. Este guia abrange todos os aspectos da implementação de RLS, desde a função estática mais simples até a segurança dinâmica complexa com integração do Azure Active Directory.

---

Principais conclusões

• A segurança em nível de linha no Power BI filtra dados em nível de modelo usando expressões DAX, garantindo que os usuários não possam ignorar a segurança modificando relatórios ou elementos visuais
• Valores de filtro de códigos rígidos RLS estáticos (adequados para grupos de usuários pequenos e estáveis), enquanto RLS dinâmico usa funções DAX como USERNAME() e USERPRINCIPALNAME() para filtrar dinamicamente com base no usuário conectado
• O RLS funciona apenas nos modos Importação e DirectQuery --- não se aplica a conexões em tempo real com o Analysis Services (que possuem seu próprio RLS)
• A segurança em nível de objeto (OLS) oculta tabelas ou colunas inteiras, complementando a RLS para cenários em que os usuários nem deveriam saber que determinados dados existem
• O teste de RLS requer o recurso "Visualizar como" no Power BI Desktop e Serviço --- nunca presuma que o RLS funciona sem testes explícitos para cada função
• RLS em cenários incorporados (Power BI Embedded) requer a passagem da identidade efetiva no token incorporado, que é uma fonte comum de erros de implementação
• O impacto do RLS no desempenho é normalmente inferior a 5% para modelos bem projetados, mas filtros DAX mal escritos podem degradar o desempenho em 50% ou mais

---

Compreendendo a segurança em nível de linha

O que o RLS faz

O RLS aplica expressões de filtro DAX a uma ou mais tabelas em um modelo de dados do Power BI. Quando um usuário abre um relatório, o Power BI avalia as regras de RLS e filtra silenciosamente as linhas que o usuário não está autorizado a ver. O usuário experimenta um relatório normal – ele simplesmente não consegue ver dados fora de seu escopo.

Criticamente, o RLS opera na camada do modelo de dados, não na camada de relatório. Isso significa:

• Os usuários não podem ignorar o RLS criando seus próprios relatórios no mesmo conjunto de dados
• Os filtros RLS se propagam por meio de relacionamentos (um filtro em Dim_Region filtra automaticamente Fact_Sales por meio do relacionamento)
• As medidas DAX respeitam o contexto RLS (CALCULATE, SUMX e outras funções operam no subconjunto filtrado)
• Exportar para Excel, CSV ou PowerPoint exporta apenas os dados que o usuário está autorizado a ver

RLS versus outros mecanismos de segurança

RLS é o único mecanismo que controla quais linhas específicas de dados um usuário pode acessar. Os outros mecanismos controlam o acesso no nível do espaço de trabalho, relatório ou objeto.

---

Segurança estática em nível de linha

O RLS estático atribui usuários a funções com valores de filtro codificados. Esta é a implementação mais simples e funciona bem para cenários com um pequeno número de regiões, departamentos ou unidades de negócios fixas.

Criando uma função estática

No Power BI Desktop:

1. Vá para Modelagem e depois Gerenciar Funções
2. Clique em Criar para adicionar uma nova função
3. Dê um nome à função (por exemplo, "Vendas na América do Norte")
4. Selecione a tabela a ser filtrada (por exemplo, Dim_Region)
5. Escreva a expressão do filtro DAX:

[Region] = "North America"

Esta expressão significa: quando um usuário recebe a função "Vendas na América do Norte", todas as tabelas relacionadas a Dim_Region mostrarão apenas linhas onde a região for América do Norte. Um usuário que visualizar um relatório de vendas verá apenas as vendas na América do Norte. Um usuário que visualizar um painel de RH (se ele se conectar por meio de uma dimensão regional) verá apenas funcionários norte-americanos.

Múltiplas funções

Você pode criar várias funções com filtros diferentes:

• Vendas EMEA: [Region] = "EMEA"
• Vendas APAC: [Region] = "APAC"
• Executivo Global: Sem filtro (vê todos os dados)

Um usuário pode ser atribuído a diversas funções. Quando atribuídos a diversas funções, os filtros combinam-se com a lógica OR --- o usuário vê a união dos dados de todas as funções. Por exemplo, um usuário atribuído a "Vendas na América do Norte" e "Vendas EMEA" vê dados de ambas as regiões.

Limitações do RLS estático

O RLS estático torna-se incontrolável quando:

• Você tem mais de 10 a 15 valores de filtro distintos (criar e manter mais de 15 funções é tedioso)
• As atribuições de usuário para função mudam frequentemente (cada alteração requer um administrador do Power BI)
• A lógica do filtro é mais complexa do que a simples igualdade (por exemplo, os gestores devem ver os dados da sua equipe mais os seus próprios)
• Você tem centenas de usuários em dezenas de unidades de negócios

Para estes cenários, o RLS dinâmico é a solução.

---

Segurança dinâmica em nível de linha

O RLS dinâmico usa funções DAX que são avaliadas em tempo de execução para determinar o usuário conectado e aplicar filtros apropriados. As duas funções principais são:

• USERNAME() — Retorna o domínio\nome de usuário ou UPN do usuário atual
• USERPRINCIPALNAME() — Retorna o email/UPN do usuário atual (recomendado para implantações em nuvem)

Configurando RLS Dinâmico

Etapa 1: Crie uma tabela de mapeamento de segurança

Esta tabela mapeia os usuários para seu escopo de dados autorizado. Ele pode ser armazenado na fonte de dados (banco de dados), em uma lista do SharePoint ou em um arquivo Excel:

Importe esta tabela para o seu modelo do Power BI como SecurityMapping.

Etapa 2: Criar a função RLS

Crie uma única função (por exemplo, "DynamicSecurity") com um filtro DAX na tabela de mapeamento de segurança:

[UserEmail] = USERPRINCIPALNAME()
    || [UserEmail] = "ALL"

Etapa 3: Criar relacionamentos

Estabeleça relacionamentos do SecurityMapping com suas tabelas de dimensões:

• SecurityMapping[Região] para Dim_Region[Região]
• SecurityMapping[Departamento] para Dim_Department[Departamento]
• SecurityMapping[CompanyId] para Dim_Company[CompanyId]

Esses relacionamentos devem ser um para muitos da dimensão para a tabela de mapeamento de segurança ou você pode usar um filtro cruzado bidirecional. No entanto, os filtros bidirecionais têm implicações de desempenho – uma abordagem melhor usa CROSSFILTER ou TREATAS na expressão DAX.

Etapa 4: Alternativa sem relacionamentos (abordagem TREATAS)

Em vez de criar relacionamentos a partir da tabela de mapeamento de segurança, você pode usar TREATAS diretamente na expressão RLS na tabela de fatos:

VAR CurrentUser = USERPRINCIPALNAME()
VAR UserRegions =
    CALCULATETABLE(
        VALUES(SecurityMapping[Region]),
        SecurityMapping[UserEmail] = CurrentUser
            || SecurityMapping[UserEmail] = "ALL"
    )
RETURN
    [Region] IN UserRegions

Essa abordagem evita a complexidade de relacionamentos adicionais e mantém a lógica de segurança independente.

RLS dinâmico com hierarquia de gerente

Um requisito comum é que os gerentes vejam os dados de toda a sua cadeia hierárquica. Isso requer uma hierarquia pai-filho na tabela de funcionários ou usuários.

Abordagem 1: função PATH

Se sua tabela de usuário tiver uma coluna ManagerId, use a função PATH do DAX:

UserPath = PATH(Users[UserId], Users[ManagerId])

Então na expressão RLS:

VAR CurrentUserId =
    LOOKUPVALUE(Users[UserId], Users[Email], USERPRINCIPALNAME())
RETURN
    PATHCONTAINS([UserPath], CurrentUserId)

Esta expressão retorna TRUE para os próprios dados do usuário atual e todos os dados pertencentes aos seus subordinados diretos e indiretos.

Abordagem 2: tabela de segurança nivelada

Pré-calcule a hierarquia em seu processo ETL e crie um mapeamento de segurança simples onde cada gerente é listado com todos os escopos de dados de seus relatórios. Isso tem melhor desempenho no momento da consulta porque evita a sobrecarga da avaliação PATH.

---

Segurança em nível de objeto (OLS)

A segurança em nível de objeto oculta tabelas ou colunas inteiras dos usuários. Ao contrário do RLS, que filtra linhas, o OLS torna tabelas ou colunas completamente invisíveis – elas não aparecem na lista de campos e qualquer referência visual a um campo oculto mostra um erro.

Quando usar o OLS

• Ocultar colunas salariais em conjuntos de dados de RH de usuários que não são de RH
• Ocultar tabelas relacionadas a custos das equipes de vendas que deveriam ver apenas receitas
• Ocultar PII do cliente (e-mail, telefone, endereço) de analistas que precisam apenas de dados agregados
• Ocultar colunas de preços estratégicos de usuários em geral

Configurando OLS

O OLS é configurado por meio do Editor Tabular (uma ferramenta externa) ou de pontos de extremidade XMLA, e não por meio da UI do Power BI Desktop.

No Editor Tabular:

1. Abra o modelo através da faixa de ferramentas externas
2. Navegue até a tabela ou coluna que deseja restringir
3. No painel Propriedades, encontre Permissões de Tabela ou Permissões de Coluna em cada função
4. Defina a permissão como "Nenhum" (o padrão é "Ler")

Por exemplo, para ocultar a coluna Salário na tabela Funcionários da função "Vendas":

• Função: Vendas
• Tabela: Funcionários
• Coluna: Salário
• Permissão: Nenhuma

Os usuários atribuídos à função Vendas não verão a coluna Salário na lista de campos e não poderão referenciá-la nos cálculos DAX.

Limitações do OLS

• OLS requer Power BI Premium ou Pro com pontos de extremidade XMLA habilitados
• O OLS não pode ser configurado na UI nativa do Power BI Desktop
• OLS é apenas no nível de metadados --- ele não filtra linhas
• Se uma medida fizer referência a uma coluna oculta, a própria medida apresentará erro para usuários restritos

---

RLS com DirectQuery

O RLS funciona com o DirectQuery, mas o comportamento é diferente do modo de importação em aspectos importantes.

Como funciona

No modo DirectQuery, o Power BI converte o filtro RLS DAX em uma cláusula SQL WHERE e o envia para a fonte de dados. A fonte de dados realiza a filtragem e somente as linhas autorizadas são retornadas.

Passagem de logon único (SSO)

Ao utilizar o DirectQuery com SSO para uma base de dados como o Azure SQL ou o Azure Synapse, o Power BI passa a identidade do utilizador para a base de dados. Se o banco de dados tiver sua própria segurança em nível de linha (por exemplo, CREATE SECURITY POLICY do SQL Server), essa segurança será aplicada além do RLS do Power BI.

Importante: se você habilitar a passagem de SSO, o RLS do Power BI será ignorado porque o banco de dados trata da segurança. Você deve escolher um ou outro:

• Power BI RLS (definido em DAX, gerenciado em Power BI)
• RLS em nível de banco de dados (definido em SQL, gerenciado no banco de dados)
• Ambos (Power BI RLS E RLS de banco de dados se aplicam --- o usuário vê a interseção)

Considerações de desempenho

Os filtros RLS no DirectQuery adicionam cláusulas WHERE a cada consulta. Se as colunas de filtro não estiverem indexadas no banco de dados, o desempenho poderá diminuir significativamente. Certifique-se de que:

• Colunas de filtro RLS possuem índices de banco de dados
• A expressão do filtro DAX é simples o suficiente para ser traduzida em SQL eficiente
• Você testa o desempenho da consulta com o "Performance Analyzer" no Power BI Desktop

---

RLS no Power BI Embedded

O Power BI Embedded (incorporação de relatórios em aplicativos personalizados) tem requisitos exclusivos de RLS porque os usuários finais podem não ter contas do Power BI ou do Azure AD.

Cenário de dados de propriedade do aplicativo

No padrão de incorporação "O aplicativo possui dados", uma entidade de serviço ou conta mestra é autenticada no Power BI e o aplicativo transmite a identidade do usuário no token incorporado.

Gerando um token incorporado com RLS:

Ao chamar a API REST do Power BI para gerar um token incorporado, inclua o parâmetro identities:

{
  "datasets": [
    {
      "id": "dataset-guid-here"
    }
  ],
  "reports": [
    {
      "id": "report-guid-here"
    }
  ],
  "identities": [
    {
      "username": "[email protected]",
      "roles": ["DynamicSecurity"],
      "datasets": ["dataset-guid-here"]
    }
  ]
}

O valor username é o que USERPRINCIPALNAME() retorna na expressão DAX. A matriz roles especifica quais funções RLS aplicar. Você pode passar qualquer string como nome de usuário --- não precisa ser uma conta real do Azure AD.

Erros comuns de incorporação

Erro 1: não transmitir a identidade efetiva. Se você gerar um token incorporado sem o parâmetro identities, o relatório incorporado mostrará todos os dados. Este é o erro de incorporação de RLS mais comum.

Erro 2: passar funções, mas não nome de usuário. O nome de usuário é necessário para RLS dinâmico. Sem ele, USERPRINCIPALNAME() retorna em branco e o filtro DAX não corresponde a nenhuma linha --- o relatório aparece vazio.

Erro 3: usar a identidade da entidade de serviço. A entidade de serviço é um administrador do workspace e ignora o RLS. Você deve transmitir explicitamente a identidade do usuário final.

Erro 4: Funções de codificação no token incorporado para RLS dinâmico. Se você usar RLS dinâmico com uma única função (por exemplo, "DynamicSecurity"), sempre passe esse nome de função. Não crie funções separadas para cada usuário – isso anula o propósito do RLS dinâmico.

---

Testando segurança em nível de linha

Exibir como função (Power BI Desktop)

No Power BI Desktop, vá para Modelagem e Exibir como:

1. Selecione as funções a serem testadas
2. Opcionalmente, insira um nome de usuário para testar RLS dinâmico (isso simula o valor USERPRINCIPALNAME())
3. Clique em OK

O relatório agora exibe dados como se você fosse o usuário especificado com a função especificada. Verifique:

• Os cartões KPI mostram os totais filtrados corretos
• As tabelas exibem apenas linhas dentro do escopo do usuário
• Os gráficos refletem os dados filtrados
• A filtragem cruzada entre recursos visuais respeita os limites do RLS
• As páginas de drill through mantêm o contexto RLS

Exibir como (serviço do Power BI)

No serviço Power BI, abra as configurações do conjunto de dados e selecione Segurança. Você pode testar funções diretamente selecionando "Testar como função" e inserindo um nome de usuário.

Lista de verificação de testes automatizados

Crie uma matriz de teste com os seguintes cenários:

---

Otimização de desempenho para RLS

Meça o impacto

Antes e depois de implementar o RLS, utilize o Analisador de Desempenho no Power BI Desktop para medir os tempos de consulta. Abra o painel Performance Analyzer, comece a gravar, interaja com o relatório e compare os tempos de consulta DAX com e sem RLS.

Uma implementação de RLS bem projetada adiciona menos de 5% de sobrecarga. Se você observar mais de 10% de degradação, investigue as expressões do filtro DAX.

Técnicas de otimização

Mantenha as expressões de filtro simples. A expressão RLS ideal é uma comparação de coluna única:

[Region] = USERPRINCIPALNAME()

Evite expressões complexas com múltiplas chamadas CALCULATE, FILTER ou LOOKUPVALUE no próprio filtro RLS.

Use chaves inteiras em vez de comparações de texto. A filtragem em [CompanyId] = 1 é mais rápida que em [CompanyName] = "ECOSIRE Private Limited". Mapeie e-mails de usuários para chaves inteiras na tabela de mapeamento de segurança.

Minimize o número de tabelas com filtros RLS. Aplique RLS a tabelas de dimensões e deixe a propagação de relacionamento lidar com tabelas de fatos. Aplicar RLS diretamente a grandes tabelas de fatos força o Power BI a avaliar o filtro em cada linha da tabela de fatos.

Pré-agregar quando possível. Se um usuário precisar apenas de dados em nível de resumo, considere criar uma tabela pré-agregada com o filtro de segurança aplicado durante o ETL. Isso reduz o volume de dados que o Power BI precisa filtrar no momento da consulta.

Evite filtros cruzados bidirecionais. Os relacionamentos bidirecionais aumentam a complexidade da consulta e podem entrar em conflito com o RLS. Use relacionamentos unidirecionais (de dimensão para fato) e aplique RLS no lado da dimensão.

---

Armadilhas e soluções comuns

Armadilha 1: RLS não aplicado a administradores de espaço de trabalho

Administradores e membros do workspace com permissão de edição ignoram o RLS. Eles sempre veem todos os dados. Isso ocorre por design: os administradores precisam de acesso total para gerenciar o espaço de trabalho.

Solução: use a função "Visualizador" para usuários corporativos que deveriam estar sujeitos à RLS. Conceda funções de administrador/membro/colaborador apenas à equipe de BI.

Armadilha 2: ALL() Removendo filtros RLS

A função DAX ALL() remove todos os filtros de uma tabela, incluindo filtros RLS. Se uma medida usar ALL() em uma tabela filtrada por RLS, ela poderá expor dados que o usuário não deveria ver.

-- DANGEROUS: This measure ignores RLS on Dim_Region
Total Global Sales =
CALCULATE(SUM(Fact_Sales[Revenue]), ALL(Dim_Region))

Solução: Use ALLSELECTED() em vez de ALL() quando quiser remover filtros visuais/de segmentação, mas preservar os filtros RLS:

-- SAFE: This measure preserves RLS filters
Total Sales for Context =
CALCULATE(SUM(Fact_Sales[Revenue]), ALLSELECTED(Dim_Region))

Armadilha 3: CALCULAR RLS de substituição

CALCULATE com argumentos de filtro explícitos pode substituir RLS em determinados cenários, particularmente com REMOVEFILTERS:

-- DANGEROUS: REMOVEFILTERS is equivalent to ALL
Total Revenue All Regions =
CALCULATE(SUM(Fact_Sales[Revenue]), REMOVEFILTERS(Dim_Region[Region]))

Solução: Audite todas as medidas DAX para uso de ALL, REMOVEFILTERS e ALLEXCEPT. Certifique-se de que eles não façam referência a colunas filtradas por RLS.

Armadilha 4: Modelos Compostos e RLS

Em modelos compostos (combinando Import e DirectQuery), o RLS deve ser definido separadamente para tabelas de importação e tabelas de DirectQuery. Uma única função RLS pode conter filtros para ambos, mas o comportamento é diferente:

• Importar tabelas: o filtro RLS é avaliado pelo mecanismo Power BI
• Tabelas DirectQuery: o filtro RLS é traduzido para SQL e enviado para a origem

Se a origem do DirectQuery não oferecer suporte à função DAX usada no filtro RLS, a consulta falhará.

Armadilha 5: Relatórios paginados ignorando RLS

Os relatórios paginados do Power BI (criados no Report Builder) podem ignorar o RLS do conjunto de dados se se conectarem diretamente à fonte de dados. Para impor o RLS, os relatórios paginados devem conectar-se por meio do conjunto de dados do Power BI (não diretamente ao banco de dados) e o usuário deve ter uma função de RLS atribuída.

---

Padrão de arquitetura RLS empresarial

Para grandes organizações, ECOSIRE recomenda uma arquitetura RLS padronizada:

Design da camada de segurança

1. Tabela de mapeamento de segurança armazenada em um banco de dados central (lista Azure SQL ou SharePoint)
2. Função RLS única chamada "DynamicSecurity" usando USERPRINCIPALNAME()
3. Sincronização de grupo do Azure AD que preenche automaticamente a tabela de mapeamento de segurança com base na associação ao grupo
4. Suporte de hierarquia usando uma tabela pai-filho pré-achatada
5. Trilha de auditoria registrando quais usuários acessaram quais dados (por meio de logs de atividades do Power BI e da API REST)

Processo de Governança

1. Os administradores de dados mantêm a tabela de mapeamento de segurança
2. As mudanças são revisadas e aprovadas por meio de um processo de gestão de mudanças
3. Auditorias mensais comparam atribuições de RLS do Power BI com o sistema de registro de RH
4. Testes de penetração trimestrais verificam a eficácia do RLS

Essa arquitetura pode ser dimensionada para milhares de usuários em centenas de conjuntos de dados, mantendo um único ponto de administração de segurança.

---

Perguntas frequentes

O RLS funciona com licenças gratuitas do Power BI?

Não. O RLS exige licenças do Power BI Pro ou Premium por usuário para todos os usuários que consomem relatórios protegidos por RLS. Os usuários de licença gratuita só podem acessar o conteúdo em um espaço de trabalho de capacidade Premium e, mesmo assim, precisam de uma licença Pro ou PPU para receber funções RLS. Em cenários do Power BI Embedded, os usuários finais não precisam de licenças do Power BI --- o RLS é aplicado por meio do token incorporado.

Posso implementar RLS com base em grupos do Azure AD em vez de usuários individuais?

Não diretamente. O RLS do Power BI avalia expressões DAX em relação a USERPRINCIPALNAME(), que retorna o email do usuário individual. No entanto, você pode criar uma tabela de mapeamento de segurança que mapeia grupos do Azure AD para escopos de dados e preenchê-la usando a API do Microsoft Graph ou a sincronização de membros do grupo do Azure AD. A expressão DAX ainda filtra pelo email do usuário, mas a tabela de mapeamento de segurança fornece o mapeamento de grupo para dados.

O que acontece se um usuário não for atribuído a nenhuma função RLS?

Se o RLS estiver definido em um conjunto de dados e um usuário não estiver atribuído a nenhuma função, o usuário não verá nenhum dado. O relatório é carregado, mas todos os elementos visuais aparecem em branco ou zero. Este é o padrão seguro --- O Power BI não assume nenhum acesso, a menos que seja explicitamente concedido. No entanto, os administradores e membros do espaço de trabalho com permissão de edição ignoram o RLS e sempre veem todos os dados, independentemente das atribuições de função.

O RLS pode filtrar dados em painéis em tempo real?

Sim. O RLS funciona com os modos Importação e DirectQuery. No modo DirectQuery, o filtro RLS é traduzido em uma cláusula SQL WHERE e enviado ao banco de dados com cada consulta, para que a filtragem ocorra em tempo real. No modo Importação, a filtragem é aplicada na memória quando o usuário abre o relatório. Ambos os modos oferecem a mesma garantia de segurança – o usuário vê apenas os dados autorizados.

Como faço para auditar quem acessou quais dados por meio do RLS?

O Power BI fornece logs de atividades por meio do centro de administração do Microsoft 365 e da API REST do Power BI. Esses logs registram visualizações de relatórios, atualizações de conjuntos de dados e operações de exportação, incluindo a identidade do usuário. No entanto, os logs não registram quais linhas específicas um usuário visualizou. Para auditoria detalhada de acesso a dados, habilite a auditoria em nível de banco de dados (por exemplo, pgaudit PostgreSQL ou auditoria SQL do Azure) para registrar as consultas reais geradas pelo DirectQuery com filtros RLS aplicados.