Недавно мы писали о том, как реализовать динамическую защиту на уровне строк в Power BI. Этот пост является дополнением к этому посту. У многих возникли вопросы: «Что делать, если я хочу, чтобы пользователи видели свои собственные данные, а менеджер - все?» или «Как добавить доступ уровня менеджера или директора к динамической безопасности на уровне строк?» В этом посте будет дан ответ на этот вопрос. Мы опишем сценарий, в котором вы можете реализовать динамическую защиту на уровне строк. В этом сценарии каждый увидит свои данные, а менеджер увидит все.

Руководство по безопасности на уровне строк

В Power BI вы можете реализовать защиту на уровне строк таким образом, чтобы пользователь ограничил доступ к содержимому отчета. Это называется безопасность на уровне строк. Существуют разные способы обеспечения безопасности на уровне строк в Power BI. Давайте посмотрим на каждый из них.

Статическая защита на уровне строк

Логика безопасности статична в определении роли, мы называем ее статической безопасностью на уровне строк. чтобы узнать больше об этом, прочитайте этот пост в блоге.

Безопасность на уровне строк в SSAS Live Connection

В этом случае отчет Power BI подключается в режиме реального времени к модели SSAS. Имя пользователя будет проходить через информацию о действующем имени пользователя, чтобы узнать больше об этом, прочитайте этот пост.

Динамическая безопасность на уровне строк

Когда у вас слишком много ролей, реализация статических ролей не вариант. Вам необходимо создать одну роль и поддерживать логику безопасности в модели данных. Это называется динамической безопасностью на уровне строк. Чтобы узнать больше об этом, прочитайте этот пост.

Дополнение к Dynamic RLS

Пример динамического RLS, который мы объяснили в этом посте, не включает доступ уровня администратора. Иногда вам нужен менеджер, чтобы иметь доступ ко всем данным. Этот текущий пост объясняет, как это сделать;

Образец набора данных

Чтобы создать сценарий с доступом на уровне менеджера и на уровне сотрудника, мы создали две таблицы, как показано ниже.

Sales Rep Table. В этой таблице есть поле “Is Manager”, значения равны нулю или единице. Если значение равно единице, то торговый представитель является менеджером и может видеть все, если значение равно нулю, тогда торговый представитель должен видеть только свои строки данных.

У нас также есть таблица Transactions, которая включает все транзакции. D этой таблице есть поле, которое является ссылкой на торгового представителя.

Очевидно, что отношения этих двух таблиц основаны на Sales Rep и поле ID.

Создание роли

Как видно из таблицы данных, мы можем легко определить, какие транзакции продаж какому торговому представителю принадлежат. Таким образом, логику ролей для получения только строк для каждого торгового представителя можно легко реализовать с помощью фильтра DAX, например:

'Sales Rep'[Email]=Username()

Мы объяснили этот метод ранее подробно здесь. Однако этот метод не работает, когда у вас есть еще и  доступ уровня «менеджер». Для доступа уровня менеджера мы можем внести некоторые изменения. Есть несколько способов его реализации. Вот один из способов сделать это:

Первый шаг. Определите пользователя

Самым первым шагом всегда является определение лица, вошедшего в отчет в Power BI Service. Это можно сделать с помощью функций Username () или UserPrincipalName () в DAX.

Второй шаг. Является ли зарегистрированный пользователь менеджером или нет?

Мы можем использовать выражение DAX, чтобы определить, является ли менеджером вошедший в отчет человек. Это можно сделать с помощью простого выражения MAXX, как показано ниже:

В приведенном выше выражении мы используем FILTER (), чтобы идентифицировать все строки таблицы торговых представителей, где адрес электронной почты соответствует зарегистрированному пользователю. Затем мы получаем максимальное значение [Is Manager] из этого значения с помощью функции MAXX (). Если результат вышеприведенного выражения равен 1, то человек является менеджером, в противном случае нет.

Если пользователь не является менеджером, покажите только записи, связанные с пользователем

Если пользователь не является менеджером, то мы просто показываем данные, связанные с ним. Это может быть выражение, как показано ниже:

'Sales Rep'[Email]=Username()

Если пользователь - менеджер, то покажите все данные

Простой способ показать все - написать DAX-выражение, которое в результате всегда возвращает true. Так же просто, как:

1=1

Все в одном

Теперь, если мы объединим все эти коды и логику вместе, мы получим следующее выражение:

Выражение выше покажет все менеджеру и только связанные данные покажет пользователям, не являющимся менеджерами.

Вы можете создать роль в Power BI в таблице Sales Rep с помощью приведенного выше выражения:

Проверьте результат

После создания этой роли опубликуйте отчет в Power BI, перейдите в раздел Конфигурация безопасности набора данных;

Добавьте всех пользователей в роль.От этого не будет никакого вреда. Если пользователя нет в вашем списке торговых представителей, он ничего не увидит. Если они есть, они будут иметь ограниченный доступ.

Затем поделитесь панелью также со всеми пользователями.

Это то, что увидит Реза (ограниченный пользователь, не являющийся менеджером);

А это то, что увидит Марк (пользователь-менеджер):

Резюме

Таким образом, это была надстройка к посту безопасности на уровне строк. Из этого поста вы узнали, как реализовать динамическую защиту на уровне строк с доступом на уровне менеджера. Этот метод реализован очень просто, есть и другие способы его реализации. В будущем мы расскажем и о других сценариях RLS с несколькими профилями пользователей

No Comments