Существуют разные методы использования безопасности на уровне строк в Power BI. Вы можете настроить безопасность на уровне строк в самой Power BI или через прямое соединение с источником данных, таким как SSAS Tabular. Однако безопасность на уровне строк, определенная способами, упомянутыми в постах выше, не является динамической. Под динамической безопасностью на уровне строк  подразумевается определение безопасности рядом с информацией об учетной записи пользователя в источнике данных. Например, когда Джон входит в систему на основе таблиц данных, которые показывают, что Джон является менеджером по продажам в конкретном филиале, он должен иметь возможность видеть только данные этого филиала. Этот метод возможен в Power BI с использованием функции DAX UserName () или UserPrincipalName(). В этой записи блога мы покажем вам пример динамической безопасности на уровне строк с функцией DAX USERNAME() в Power BIЗачем нужна динамическая безопасность на уровне строк?

Самый важный вопрос: зачем нужна динамическая безопасность на уровне строк? Чтобы ответить на этот вопрос, вам нужно подумать об ограничении статической безопасности на уровне строк. Статическая защита на уровне строк проста в реализации, однако, если у вас тысячи ролей, поддерживать ее будет кошмаром. Например, если вы хотите создать отчет Power BI для расчета заработной платы, в компании с десятью тысячами пользователей вы хотите, чтобы каждый пользователь имел свою роль. Динамическая безопасность на уровне строк является ответом для таких сценариев.

Пример данных

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

Для этого примера давайте создадим две простые таблицы: Sales Rep и Transactions. Sales Rep имеет информацию о торговых представителях, а данные о транзакциях являются торговыми операциями. Очевидно, что каждая торговая операция обрабатывается торговым представителем. Итак, давайте создадим образцы таблиц в Power BI. Откройте Power BI Desktop и в разделе External Data section выберите Enter Data.

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

Создайте еще одну таблицу для транзакций со структурой ниже и назовите ее Transactions:

Как вы можете видеть на скриншоте выше, каждая торговая операция обрабатывается торговым представителем. Еще раз отметим, что эти таблицы добавлены в Power BI только для простоты этого примера. Таблицы могут быть взяты овсюду.

Загружайте таблицы в Power BI, нам не нужно ничего делать с Power Query на этом этапе. Перейдите на вкладку Relationship  и убедитесь, что отношения между Sales Rep (ID) и Transactions (Sales Rep) имеют следующий вид:

Образец отчета

В этом примере мы будем использовать базовую визуализацию таблиц. Визуализация таблицы покажет  Date, Sales Amount (из Transactions), и Name (из Sales Rep). Мы также добавили еще одну визуализацию таблицы для отображения имени пользователя и Name (оба из Sales Rep);

Основная причина этой визуализации - просто показать, что каждый пользователь будет видеть только свои строки данных из всех таблиц. Мы также добавим показатель для USERNAME () в DAX, чтобы пользователь вошел в наш отчет. Поэтому на вкладке Data создайте новую меру и назовите ее User, со значением USERNAME ();

Мы также хотели бы добавить дату / время обновления отчета с помощью функции DAX NOW () (обратите внимание, что функция NOW () будет возвращать текущее время сервера, а не локальное. Итак, давайте создадим новое измерение и назовем его Now:

Теперь давайте добавим две другие визуализации таблицы в отчет. Один для User, а другой для Now. Вот окончательный вид отчета:

Функции DAX: UserName () и UserPrincipalName ()

Функция USERNAME () в DAX возвращает имя пользователя, вошедшего в систему. Однако для этого есть небольшая хитрость. Если мы не настроим защиту на уровне строк для нашего отчета, функция USERNAME () вернет идентификатор пользователя, который будет уникальным идентификатором. Чтобы понять, что здесь подразумевается, опубликуйте свой отчет в Power BI и просмотрите его, чтобы увидеть следующее:

Без настройки безопасности в вашем отчете вы увидите уникальный идентификатор для имени пользователя, который бесполезен. Теперь давайте настроим защиту на уровне строк и назначим пользователей, чтобы посмотреть, как она работает.

Функция UserPrincipalName() в DAX работает точно так же, как и функция UserName(), с той разницей, что она всегда будет возвращать имя пользователя (а не уникальный идентификатор). Таким образом, в основном UserPrincipalName() является лучшей функцией для тестирования, но в производственной среде работает одинаково. Теперь давайте настроим защиту на уровне строк и назначим пользователей, чтобы посмотреть, как она работает.

Безопасность на уровне строк в Power BI Desktop

В другом посте мы объяснили, как работает защита на уровне строк в Power BI Desktop, поэтому, если вы хотите узнать об этом подробнее, прочитайте этот пост в блоге. Здесь мы будем использовать эту технику только для фильтрации каждой роли по имени пользователя с помощью функции DAX username (). Чтобы создать защиту, перейдите на вкладку Modeling (для этого примера необходимо обновление Power BI не позднее июня 2016 года), Manage Roles. Создайте роль и назовите ее Sales Rep. И определите фильтр в таблице Sales Rep, как показано ниже:

[Username] = USERNAME()

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

Назначение пользователей в Power BI Security

Теперь сохраните и опубликуйте свое решение в Power BI. В службе Power BI перейдите к настройке безопасности набора данных, который вы только что опубликовали (мы назвали это Dynamic RLS).

А на вкладке Security  добавьте всех пользователей в роль Sales Rep.

Обратите внимание, что добавление сюда пользователя не означает, что он увидит данные в отчете. Помните, что эта защита является динамической, означает, что они будут видеть свои строки данных ТОЛЬКО, если базовый набор данных имеет запись для своего имени пользователя, и они будут видеть только строки данных, связанные с их именем пользователя, но не другие.

Теперь, если вы обновите отчет в Power BI, вы увидите реальные имена пользователей. Поскольку мы уже настроили для него безопасность, он больше не показывает уникальные идентификаторы.

Поделитесь панелью инструментов

Другие пользователи должны иметь доступ к панели инструментов. Создайте панель мониторинга из главной таблицы в отчете, назовите панель управления как RLS (или как вы хотите ее назвать):

Теперь поделитесь панелью с другими пользователями

Проверьте безопасность

Теперь, если другие пользователи откроют отчет и их имена совпадают с одной из записей в таблице Sales Rep, они увидят свои имена и строки данных, связанные с этим в отчете:

Как вы можете видеть, Джон Мартин видит только транзакцию, которую он обработал, и его запись в таблице Sales Rep. Снимок экрана, показанный выше, представляет собой представление Джона о Power BI. Хотя наше отображение этого отчета будет другим, мы увижу две мои транзакции и наше имя в разделе Sales Rep.

Резюме

Вы видели, как легко использовать динамическую защиту на уровне строк в Power BI с помощью функции DAX USERNAME () или UserPrincipalName (). С помощью этого метода пользователи увидят свое представление. Однако вам необходимо убедиться, что ваша модель Power BI имеет правильно настроенные отношения. В противном случае люди могут увидеть данные другой таблицы, если между их таблицей профилей и таблицами нет никакой связи. Динамическая безопасность на уровне строк сильно зависит от вашей модели данных, поэтому сохраняйте правильность вашей модели данных.

No Comments