Самым популярным методом ограничения доступа к данным в отчете Power BI остается Row-level Security (RLS), с помощью которого у каждого пользователя есть доступ к набору данных согласно его учетной записи или роли. В этом случае пользователь видит все страницы и объекты отчета, которые отражают результаты согласно ограничениям, наложенным на датасет.

Но зачастую этого становится недостаточно и появляется необходимость в ограничении доступа не только к строкам датасета, по которым будет построен отчет, но и к страницам целиком и даже к отдельным объектам видимых страниц.

Вопрос реализации RLS подробно освещён, поэтому останавливаться на деталях не буду. Вместо этого сконцентрируюсь на двух других способах: ограничении доступа к страницам и объектам.

Ограничение доступа к страницам и объектам в Power BI
Ограничение доступа к страницам и объектам в Power BI

Page-level security (PLS)

Power BI не предлагает никаких инструментов, напрямую направленных на поддержку безопасности на уровне страниц отчета. Стандартная функция «скрыть страницу» никак не регулируется учётными записями. Это критическое ограничение требует использования комбинированного подхода.

Задача:

На дашборде 4 страницы:

Главная - видят все пользователи

Страница 1 - видит только руководитель

Страница 2 - видят только руководитель и одна группа пользователей

Страница 3 - видят только руководитель и вторая группа пользователей

Шаг 1 - Создать нужное количество страниц дашборда и скрыть их

Создаём страницы
Создаём страницы

Шаг 2 - Определиться с ролями

Каждая роль предполагает определенный набор страниц.

Users = DATATABLE(
    "UserID", INTEGER,
    "Email", STRING,
    "Position", STRING,
    "Role", INTEGER,
    {
        {1, "chief@company.ru", "Chief", 1},
        {2, "analyst2@company.ru", "Analyst", 2},
        {3, "analyst3@company.ru", "Analyst", 2},
        {4, "analyst4@company.ru", "Analyst", 2},
        {5, "analyst5@company.ru", "Analyst", 3},
        {6, "analyst6@company.ru", "Analyst", 3},
        {7, "analyst7@company.ru", "Analyst", 3}
    }
)

Шаг 3 - Создаём меру для каждой страницы, требующей ролевого доступа

page_1 = if(CALCULATE(max(Users[User]), Users[Role] = USERPRINCIPALNAME()) = 1, 
"Страница 1", blank())

page_2 = if(CALCULATE(max(Users[User]), Users[Role] = USERPRINCIPALNAME()) in {1, 2}, 
"Страница 2", blank())

page_3 = if(CALCULATE(max(Users[User]), Users[Role] = USERPRINCIPALNAME()) in {1, 3}, 
"Страница 3", blank())

Шаг 4 - Навигатор страниц

А если точнее - отдельные кнопки, т.к. привычный навигатор тут не поможет.

На каждой странице создаём кнопки для перехода по страницам, настраиваем их внешний вид и действие:

Тип -  перемещение по страницам

Назначение - выбираем условное форматирование и указываем соответствующую странице меру

Кнопки для перемещения по страницам
Кнопки для перемещения по страницам

Готовые кнопки копируем на все страницы.

Можно добавить условное форматирование, по которому в недоступных кнопках вместо названия страницы будет написано “недоступно” или они полностью сольются с фоном

Однако, важно понимать, что такую реализацию можно обойти через прямые URLы. Если пользователь знает название  скрытой от него страницы и как попасть на неё напрямую, дописав URL, безопасность превращается в иллюзию. Чтобы перестраховаться следует доработать скрытые страницы, добавив Object-level security (OLS), который скроет конкретные визуальные элементы для определённых ролей, блокируя доступ к конфиденциальным данным.

Object-level security (OLS)

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

Для ограничения доступа к отдельным визуальным объектам подготовим DAX – меру, которая проверяет текущую учётную запись пользователя или её принадлежность к конкретной роли и возвращает булево значение 0 или 1. Мера добавляется в панель фильтров данного визуального элемента с установкой фильтрации по значению, обеспечивающему видимость элемента для разрешенных пользователей. При этом сам визуальный объект остается на странице, но его содержимое скрыто от определенных пользователей.

Воспользуемся таблицей Users, созданной для примера с PLS.

Допустим необходимо на странице скрыть таблицу и срез по регионам от пользователей с ролью 3.

m_is_visible = if(CALCULATE(max(Users[Role]), Users[Email] = USERPRINCIPALNAME()) = 3, 0, 1)
Добавляем меру в панель фильтров визуального элемента "Срез" (повторяем для таблицы)
Добавляем меру в панель фильтров визуального элемента "Срез" (повторяем для таблицы)

Проверка, как конкретный пользователь (например, analyst7@company.ru) будет видеть страницу, осуществляется через вкладку «Моделирование» в Power BI Desktop с помощью функции «Просмотреть как»

Просмотреть как analyst7@company.ru
Просмотреть как analyst7@company.ru
Результат проверки доступа
Результат проверки доступа

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

Комментарии (0)