RLS, permissões e credenciais no Power BI

A RLS é o controle relevante quando duas pessoas podem acessar o mesmo relatório, mas não devem consultar as mesmas linhas. Ela é configurada por meio da criação de papéis, da seleção das tabelas protegidas e da definição de expressões DAX usadas como filtros.^[3]

A palavra papel merece atenção. Em RLS, o papel está associado ao filtro que limita os registros disponíveis.^[1] Já no contexto de permissões, os papéis representam capacidades diferentes sobre relatórios, pastas, recursos, metadados e permissões.^[2] Embora a terminologia seja parecida, os controles descritos pelas fontes não têm a mesma finalidade.

Antes da publicação, cada função de RLS deve ser testada no Power BI Desktop. A visualização como um papel específico permite verificar se todos os elementos do relatório mostram somente os dados permitidos para aquela função.^{[2, 3]}

Depois da publicação, usuários ou grupos de segurança do Azure Active Directory podem ser associados à função nas configurações de segurança do conjunto de dados.^[2] Essa associação identifica quem ficará sujeito ao filtro, enquanto a expressão DAX define quais registros o papel poderá consultar.^{[2, 3]}

As permissões devem ser examinadas quando a dúvida não for quais linhas aparecem, mas quais ações alguém pode executar sobre os ativos. Os papéis disponíveis podem conceder capacidades distintas, incluindo visualizar, assinar, publicar ou administrar relatórios, pastas, recursos, metadados e permissões.^[2]

Também é necessário considerar a herança. Relatórios e pastas herdam, por padrão, as permissões da pasta superior, mas essa herança pode ser substituída por uma configuração específica.^[2] Assim, uma análise limitada à configuração aparente de um relatório pode não representar toda a origem da autorização. A pasta superior e uma eventual substituição específica precisam entrar na revisão.^[2]

A RLS não substitui essa verificação de autorização. Ela restringe registros mediante filtros associados a funções, enquanto as permissões concedem capacidades sobre ativos e sua administração.^{[1, 2]} Se o risco for uma pessoa publicar ou administrar algo que deveria apenas visualizar, a revisão principal pertence às permissões, não à expressão DAX da RLS.^[2]

As credenciais devem ser revisadas quando a preocupação for o acesso do Power BI Service à fonte de dados. Cada fonte deve ter suas credenciais configuradas de forma segura no serviço.^[1]

Esse controle não responde, por si só, quais linhas um usuário pode consultar em um relatório. Essa restrição é atribuída pela fonte à RLS e aos filtros associados às funções.^[1] Também não define as capacidades de visualizar, publicar ou administrar relatórios e pastas, que pertencem ao domínio das permissões.^[2]

A evidência disponível permite afirmar apenas essa separação de responsabilidades. Ela não informa como diagnosticar falhas de conexão, escolher um método de autenticação ou estabelecer uma política de rotação. Para essas decisões, seriam necessárias fontes adicionais específicas.

Considere um relatório regional já publicado. Se cada gerente deve consultar somente as linhas de sua região, o ponto de revisão é o papel de RLS, sua expressão DAX, o teste no Desktop e a associação posterior do usuário ou grupo à função no serviço.^{[2, 3]}

Se um gerente consegue publicar ou administrar o relatório quando deveria apenas visualizá-lo, devem ser verificadas as capacidades do papel e as permissões herdadas ou específicas.^[2] Se o serviço não está autorizado de forma segura a acessar a fonte, a revisão deve alcançar as credenciais configuradas para essa fonte no Power BI Service.^[1]

O exemplo mostra por que um único ajuste não cobre os três riscos. Filtro de linhas, capacidade sobre ativos e acesso à fonte são dimensões distintas nas evidências fornecidas.^{[1, 2]}

Comece pelo objeto que precisa ser protegido:

1. Se o objeto do risco são registros, examine as tabelas protegidas, os papéis, os filtros DAX e o resultado da visualização de cada função no Desktop.^{[2, 3]}
2. Se o objeto do risco é o relatório, a pasta, o recurso, o metadado ou sua administração, examine o papel concedido, a permissão herdada da pasta superior e qualquer configuração específica que substitua a herança.^[2]
3. Se o objeto do risco é a conexão do serviço com a fonte, examine as credenciais configuradas para aquela fonte no Power BI Service.^[1]

Depois, confirme onde a decisão é aplicada. A definição e o teste dos papéis de RLS ocorrem no Power BI Desktop; após a publicação, usuários ou grupos podem ser associados às funções nas configurações de segurança do conjunto de dados.^[2] As permissões podem decorrer da pasta superior ou de uma configuração específica.^[2] As credenciais são configuradas por fonte no serviço.^[1]

Para uma visão mais ampla da formação, consulte o conteúdo relacionado do curso. A referência é contextual e não amplia as evidências usadas neste artigo.