Row-level security (RLS) with Power BI (Безопасность на уровне строк (RLS) в Power BI)

Безопасность на уровне строк (RLS) ограничивает доступ к данным для конкретных пользователей Power BI семантической модели. Фильтры ограничивают данные на уровне строки и определяют фильтры в ролях. В службе Power BI пользователи с доступом к рабочей области имеют доступ к семантическим моделям в этой рабочей области. RLS ограничивает доступ только к данным для пользователей с разрешениями средства просмотра . Это не распространяется на роли рабочей области Администратор, Участник или Исполнитель.

Чтобы реализовать RLS, выполните этот высокоуровневый рабочий процесс:

1. Определите роли и правила в Power BI Desktop с помощью выражений фильтров DAX.
2. Опубликуйте семантическую модель и отчет в службу Power BI.
3. Добавьте участников в роли в службе Power BI.
4. Проверка с помощью функции "Тест в качестве роли ", чтобы убедиться, что фильтрация данных работает должным образом.

Вы можете настроить RLS для импортированных семантических моделей в Power BI Desktop или служба Power BI. Вы также можете настроить RLS в семантических моделях, использующих DirectQuery, например SQL Server. Для динамических подключений служб Analysis Services или Azure Analysis Services вы настраиваете безопасность на уровне строк в модели, а не в Power BI. Параметр безопасности не отображается для семантических моделей динамического подключения.

Определение ролей и правил в Power BI Desktop

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

Определение ролей безопасности:

1. Импортируйте данные в отчет Power BI Desktop или настройте подключение DirectQuery.

   Примечание.

   Нельзя определить роли в Power BI Desktop для подключений служб Analysis Services в режиме реального времени. Это необходимо сделать в модели служб Analysis Services.

2. На вкладке "Моделирование " выберите "Управление ролями".

3. В окне Управление ролями выберите Создать, чтобы создать новую роль.

4. В разделе "Роли" введите имя роли и нажмите Enter.

   Примечание.

   Вы не можете определить роль с запятой, например, London,ParisRole.

5. В разделе Выбор таблиц выберите таблицу, к которой вы хотите применить фильтр безопасности на уровне строки.

6. Под Фильтрация данных используйте редактор по умолчанию, чтобы определить свои роли. Созданные выражения возвращают значение true или false. Фильтр DAX возвращает значение TRUE или FALSE для каждой строки. Видимы только строки, которые возвращают значение TRUE. Всё остальное полностью удаляется.

   Примечание.

   Не все фильтры безопасности на уровне строк, поддерживаемые в Power BI, можно определить с помощью редактора по умолчанию. Ограничения включают выражения, которые сегодня можно определить только с помощью DAX, включая динамические правила, такие как username() или userprincipalname(). Чтобы определить роли с помощью этих фильтров, переключитесь на использование редактора DAX.

7. При необходимости выберите Перейти в редактор DAX чтобы использовать редактор DAX для определения вашей роли. Выражения DAX возвращают значение true или false. Например: [Entity ID] = “Value”. Редактор DAX оснащен функцией автозавершения для формул (интеллисенс). Установите флажок над полем выражения, чтобы проверить выражение и кнопку X над полем выражения, чтобы вернуть изменения.

   Примечание.

   В этом выражении можно использовать имя пользователя( ). Помните, что имя пользователя() имеет формат DOMAIN\username в Power BI Desktop. В службе Power BI и сервере отчетов Power BI это представлено в формате универсального имени пользователя (UPN). Кроме того, в этом поле выражения используйте запятые для разделения аргументов функции DAX, даже если используется языковой стандарт, который обычно использует разделители с запятой, например французский или немецкий.

8. Вы можете вернуться к редактору по умолчанию, выбрав Перейти к редактору по умолчанию. Все изменения, сделанные в любом интерфейсе редактора, сохраняются при переключении между интерфейсами, если это возможно. При определении роли с помощью редактора DAX, который не может быть определен в редакторе по умолчанию, при попытке переключиться в редактор по умолчанию появится предупреждение о том, что переключение редакторов может привести к потере некоторых сведений. Чтобы сохранить эти сведения, выберите Отмена и продолжайте изменять эту роль только в редакторе DAX.

   Примечание.

   В этом поле выражения используйте запятые для разделения аргументов функции DAX, даже если используется языковой стандарт, который обычно использует разделители с запятой, например французский или немецкий.

9. Выберите Сохранить.

Вы не можете назначать пользователей на роль в Power BI Desktop. Вы назначаете их в службе Power BI. Вы можете включить динамическую безопасность в Power BI Desktop, используя функции DAX username() или userprincipalname() и правильно настроив соответствующие связи.

Общие шаблоны фильтров DAX для ролей RLS

В следующих примерах показаны распространенные выражения фильтра DAX, которые можно использовать при определении ролей RLS в Power BI Desktop:

• Статические RLS — ограничивает данные фиксированным значением:

  [Region] = "West"
  

• Dynamic RLS with UPN — ограничивает данные на основе адреса электронной почты вошедшего пользователя:

  [UserEmail] = USERPRINCIPALNAME()
  

• Dynamic RLS with USERNAME — ограничивает данные на основе домена и имени пользователя:

  [UserDomain] = USERNAME()
  

• Dynamic RLS with CUSTOMDATA — ограничивает данные на основе пользовательской строки, передаваемой из встраиваемого приложения:

  [AppRole] = CUSTOMDATA()
  

  Примечание.

  CUSTOMDATA() в основном используется в встраиваемых сценариях, когда приложение передает собственную строку эффективного удостоверения через REST API Power BI.

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

Пример: фильтрация данных о продажах Power BI по регионам

Предположим, что у вас есть Sales таблица со столбцами Region, Productа также Amount. Вы хотите ограничить пользователей, назначенных роли "Запад", чтобы они видели только строки, в которых регион — "Запад".

В поле фильтра DAX для роли "Запад" введите следующее выражение:

[Region] = "West"

Перед фильтрацией (все данные):

После фильтрации (представление для пользователей ролей "Запад"):

Выражение DAX выступает в качестве фильтра строк, который вычисляет каждую строку в таблице. Пользователям, назначенным на эту роль, отображаются только те строки, в которых значение столбца Region равно "Запад".

Двунаправленная перекрестная фильтрация с помощью RLS

По умолчанию фильтрация безопасности на уровне строк использует однонаправленные фильтры, независимо от того, заданы ли связи однонаправленным или двунаправленным.

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

Дополнительные сведения см. в статье "Двунаправленная перекрестная фильтрация с помощью DirectQuery в Power BI " и технической статье "Защита семантической модели табличной бизнес-аналитики ".

Управление безопасностью в семантической модели

Чтобы управлять безопасностью в семантической модели, откройте рабочую область, в которой сохранена семантическая модель в Microsoft Fabric, и выполните следующие действия.

1. В Microsoft Fabric выберите меню "Дополнительные параметры" для семантической модели. Это меню отображается при наведении указателя мыши на имя семантической модели.

   

2. Выберите Безопасность.

   

Security переводит вас на страницу безопасности на уровне строк, где можно добавить участников в созданную роль. Пользователи с ролью рабочей области Участник или выше по уровню видят параметр Безопасность и могут назначать пользователям роли. Владение семантической моделью или разрешение на сборку также может потребоваться в зависимости от сценария.

Управление членством в ролях RLS в службе Power BI

Добавить участников в роль RLS

В служба Power BI можно добавить участника в роль RLS, введя адрес электронной почты или имя пользователя или группы безопасности. Нельзя добавлять группы, созданные в Power BI. Вы можете добавлять участников из вне вашей организации. Инструкции по работе RLS с внешними гостевыми пользователями B2B см. в статье "Рекомендации по внешним (гостевым пользователям B2B").

Для настройки безопасности на уровне строк можно использовать следующие Microsoft Entra ID и группы с поддержкой электронной почты:

• Группа рассылки
• Группа с поддержкой почты
• Группа безопасности Microsoft Entra — если группа безопасности содержит внешних гостевых пользователей B2B, см. Важные сведения о внешних (гостевых пользователях B2B), чтобы узнать об известных ограничениях.

Вы можете увидеть, сколько членов являются частью роли по числу в скобках рядом с именем роли или рядом с участниками.

Удалить участников из роли RLS

Вы можете удалить участников, выбрав X рядом с именем участника.

Проверьте роль в службе Power BI

Вы можете убедиться, что определённая вами роль RLS работает правильно в службе Power BI, протестировав её.

1. Выберите дополнительные параметры (...) рядом с ролью.
2. Выберите "Тест в качестве роли".

При загрузке отчета проверьте следующее:

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

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

Проверьте другие отчеты, подключенные к семантической модели, выбрав "Просмотр " в заголовке страницы. Отчеты можно тестировать только в той же рабочей области, что и семантическая модель.

Чтобы вернуться к обычному просмотру, нажмите кнопку "Вернуться к безопасности на уровне строк".

Использование функции DAX username() или userprincipalname()

Вы можете воспользоваться функциями DAX username() или userprincipalname() в наборе данных. Их можно использовать в выражениях в Power BI Desktop. При публикации модели она будет использоваться в службе Power BI.

В Power BI Desktop имя пользователя () возвращает пользователя в формате DOMAIN\User и userprincipalname() в форматеuser@contoso.com.

В службе Power BI username() и userprincipalname() возвращают учетное имя пользователя (UPN). Это выглядит примерно так, как адрес электронной почты.

Используйте RLS с рабочими областями в Power BI

Если вы публикуете отчет Power BI Desktop в рабочую область службы Power BI, роли RLS применяются к пользователям, которым назначена роль Viewer в рабочей области. Даже если пользователям с ролью Viewers предоставлено разрешение Build на семантическую модель, RLS всё равно применяется. Например, если пользователи с ролью «Средство просмотра» и разрешением Build используют Анализ в Excel, их доступ к данным ограничивается правилами RLS. Члены рабочей области, назначенные администратором, участником или участником , имеют разрешение на изменение семантической модели и, следовательно, RLS не применяется к ним. Если вы хотите, чтобы RLS применялся к людям в рабочей области, им можно назначить только роль наблюдателя. Для получения дополнительной информации см. о ролях в рабочих пространствах.

Соображения для внешних пользователей (гостевых пользователей B2B)

Если вы предоставляете общий доступ к содержимому Power BI внешним пользователям через Microsoft Entra B2B, помните о следующих рекомендациях по RLS.

Группы безопасности Microsoft Entra с внешними участниками

Группы безопасности Microsoft Entra, содержащие внешних гостевых пользователей B2B, могут работать не так, как ожидается, если они используются для определения членства в ролях RLS. В некоторых конфигурациях , особенно если внешний пользователь имеет учетную запись гостевого типа (а не учетную запись типа участника) — членство в группе гостя неправильно оценивается служба Power BI при применении фильтров RLS.

Рекомендуемый обходной путь: Вместо добавления внешних пользователей в роли RLS через группы безопасности Microsoft Entra добавляйте их напрямую в роль, указав адрес электронной почты. Адрес электронной почты сопоставляется с учетной записью B2B пользователя. Это гарантирует, что их идентификатор корректно сопоставляется при применении фильтров RLS. Дополнительные сведения см. в статье Управление членством в ролях RLS в службе Power BI.

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

Если проблема сохраняется после применения обходного решения, см. статью "Устранение неполадок: внешний гость B2B не видит данных в отчете Power BI" для получения дополнительных диагностических действий.

Сопоставление UPN для гостей B2B в Power BI RLS

Когда внешний гостевой пользователь B2B обращается к отчету Power BI, функция USERPRINCIPALNAME() DAX обычно возвращает идентификатор электронной почты (например, user@partner.com). В некоторых конфигурациях он может возвращать гостевой UPN в #EXT# формате (например, user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Это различие имеет значение для динамического RLS. Если таблица сопоставления пользователей хранит формат идентификатора, который отличается от USERPRINCIPALNAME() возвращаемого значения, выражение фильтра не будет совпадать, и в результате гостевой пользователь может не увидеть данные или получить неверные данные.

Поведение USERNAME() для гостей B2B в Power BI RLS

Функция USERNAME() DAX возвращает идентификатор пользователя domain\username . Для гостевых пользователей B2B USERNAME() часто возвращает идентификатор, похожий на UPN, аналогичный USERPRINCIPALNAME(), в зависимости от конфигурации (например, user@partner.com), а не идентификатор в формате domain\username. Так как USERNAME() и USERPRINCIPALNAME() часто возвращают одно и то же значение для гостей B2B, большинство реализаций использует USERPRINCIPALNAME() для согласованности.

Рекомендуемый подход: Храните и последовательно используйте тот же формат идентификатора в таблице сопоставления пользователей, что и возвращаемое значением USERPRINCIPALNAME(). В большинстве случаев использование адресов электронной почты упрощает управление:

[UserEmail] = USERPRINCIPALNAME()

UserEmail Где столбец содержит адреса электронной почты, например user@partner.com для внутренних и внешних пользователей.

Устранение неполадок: внешний гость B2B не видит данных в отчете Power BI

Если гостевой пользователь B2B видит пустой отчет или получает сообщение "без данных", выполните следующие действия:

1. Проверьте возвращаемый формат имени участника-пользователя (UPN) — создайте тестовую меру с помощью USERPRINCIPALNAME() и отобразите ее в визуале карточки. Просмотрите отчет гостевого пользователя, чтобы увидеть фактическое возвращаемое значение.
2. Проверьте таблицу сопоставления пользователей — убедитесь, что таблица сопоставления содержит строку со значением, которое точно совпадает с тем, что USERPRINCIPALNAME() возвращает для этого гостя.
3. Проверьте чувствительность к регистру — сравнение строк в DAX по умолчанию нечувствительно к регистру, но убедитесь, что в источнике данных не появились значения, различающиеся регистром.
4. Проверьте параметры межтенантного доступа — если в вашей организации используются политики межтенантного доступа, они могут повлиять на то, какой формат UPN отображается в Power BI.
5. Проверка с реальным гостевым пользователем — функция Тестировать как роль использует вашу собственную учетную запись. Всегда проверяйте с помощью реальной внешней гостевой учетной записи.
6. Проверка назначения ролей . Если гостевой пользователь видит больше данных, чем ожидалось, убедитесь, что они назначены роли RLS. Пользователи, которым не назначена ни одна роль RLS, обычно не видят никаких данных (получают пустой результат), поскольку RLS применяется, но подходящая роль не назначена. Фильтр DAX возвращает значение TRUE или FALSE для каждой строки. Видимы только строки, возвращающие TRUE. Все остальное полностью удалено.

Дополнительные сведения о распространении содержимого Power BI внешним гостевым пользователям см. в разделе Распространение содержимого Power BI среди внешних гостевых пользователей с помощью Microsoft Entra B2B.

Рекомендации и ограничения

Здесь можно увидеть текущие ограничения безопасности на уровне строк в облачных моделях:

• Если вы ранее определили роли и правила в служба Power BI, необходимо повторно создать их в Power BI Desktop.
• Вы можете определить RLS только в семантических моделях, созданных с помощью Power BI Desktop. Если вы хотите включить RLS для семантических моделей, созданных с помощью Excel, сначала необходимо преобразовать файлы в файлы Power BI Desktop (PBIX). Подробнее.
• Основные учетные записи службы не могут быть добавлены в роль RLS. Соответственно, RLS не применяется для приложений, использующих учетную запись службы в качестве окончательного эффективного удостоверения.
• Поддерживаются только подключения типа Import и DirectQuery. Динамические подключения к службам Analysis Services обрабатываются в локальной модели.
• С включенной функцией RLS использование функции USERELATIONSHIP() в запросах и мерах DAX может привести к непредвиденным ошибкам. Чтобы обойти эту проблему, измените выражения DAX, чтобы избежать USERELATIONSHIP() и использовать связи уровня модели или другие шаблоны DAX.
• Функция Test as role/View as role не работает для моделей DirectQuery с включенным единым входом (Single Sign-On, SSO).
• Тест в качестве роли или представления в качестве функции роли отображает только отчеты из рабочей области семантических моделей.
• Функция test as role/View as role не работает для отчетов с разбивкой на страницы.
• Удостоверение на основе токенов работает только для моделей DirectQuery, размещенных на емкости, подключенной к базе данных Azure SQL, которая настроена на разрешение аутентификации через Microsoft Entra. Дополнительные сведения см. в разделе "Внедрение отчета с удостоверением на основе токенов"
• Параметр IdentityBlob — это маркер доступа OAuth 2.0 для Azure SQL и поддерживается только для наборов данных с подключением DirectQuery к Azure SQL. Сам механизм специфичен для Azure SQL: BLOB-объект is токеном доступа Microsoft Entra с областью действия https://database.windows.net/.default. Для других источников данных не существует эквивалентного механизма передачи токена при встраивании типа App-owns-data. Дополнительные сведения см. в справочнике по REST API для GenerateToken.

Рекомендации и ограничения для динамической RLS

При использовании динамической безопасности на уровне строк (RLS) с такими функциями DAX, как USERPRINCIPALNAME(), USERNAME()или CUSTOMDATA()помните о следующих рекомендациях.

Межарендаторские сценарии B2B

В сценариях B2B USERPRINCIPALNAME() возвращает идентификатор в том виде, в котором его определяет служба Power BI, который может отличаться в зависимости от конфигурации арендатора. Она может отображаться следующим образом:

• Адрес электронной почты внешнего пользователя (user@partner.com) или
• Разрешенное клиентом значение, например user_partner.com#EXT#@tenant.onmicrosoft.com

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

Если таблица сопоставления пользователей хранит идентификаторы в другом формате, отличном от того, что USERPRINCIPALNAME() возвращается для гостевых пользователей, выражение фильтра RLS не будет совпадать, и гость не видит данных или неверных данных. Всегда проверяйте точное значение, возвращаемое USERPRINCIPALNAME() внешними пользователями в вашей среде.

Проверка ограничений роли с помощью динамической RLS

Функция Test as role в службе Power BI использует ваши учетные данные при вычислении динамических выражений RLS. Это означает, что USERPRINCIPALNAME() возвращает ваш UPN, а не UPN пользователя, которого вы пытаетесь сымитировать. Вы не можете использовать Проверка от имени роли, чтобы увидеть, что доступно конкретному гостевому пользователю B2B или субъекту-службе.

Проверка от имени роли имитирует членство в роли, но не полностью воспроизводит контекст аутентификации другого пользователя, особенно для гостей B2B или сценариев встраивания.

Чтобы проверить динамический RLS для внешних пользователей, войдите в качестве фактического гостевого пользователя и просмотрите отчет напрямую. Это единственный способ подтвердить, что USERPRINCIPALNAME() возвращает ожидаемое значение и что фильтры RLS соответствуют правильно для этого пользователя.

Внедренные сценарии с субъектами-службами

При доступе к отчету через встроенное приложение, которое выполняет аутентификацию с помощью субъекта-службы, USERPRINCIPALNAME() и USERNAME() возвращают идентификатор приложения субъекта-службы или пустую строку, а не идентификатор конечного пользователя.

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

Чтобы применять RLS на уровне отдельного пользователя во встраиваемых сценариях, используйте функцию effective identity в REST API Power BI. Передайте объект EffectiveIdentity с соответствующим именем пользователя и ролями при создании токена внедрения. Если в правилах RLS используется CUSTOMDATA(), передайте строку пользовательских данных через EffectiveIdentity.CustomData.

Дополнительные сведения см. в статье RLS для встроенных сценариев для поставщиков программного обеспечения.

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

Вопросы и ответы

Вопрос. Что делать, если ранее я создал роли и правила для набора данных в служба Power BI? Они по-прежнему работают, если я ничего не делаю?
Ответ. Нет, визуальные элементы не будут правильно отображаться. Необходимо повторно создать роли и правила в Power BI Desktop, а затем опубликовать в службу Power BI.

Вопрос. Можно ли создать эти роли для источников данных служб Analysis Services?
Ответ. Да, если вы импортировали данные в Power BI Desktop. Если вы используете динамическое подключение, вы не можете настроить RLS в службе Power BI. Вы определяете RLS в локальной модели служб Analysis Services.

Вопрос. Можно ли использовать RLS для ограничения столбцов или мер, доступных моими пользователями?
Ответ. Нет, если у пользователя есть доступ к определенной строке данных, они могут видеть все столбцы данных для этой строки. Чтобы ограничить доступ к столбцам и метаданным столбцов, рекомендуется использовать безопасность на уровне объекта.

Вопрос. Позволяет ли RLS скрывать подробные данные, но предоставлять доступ к данным, обобщенным в визуальных элементах?
Ответ. Нет, вы защищаете отдельные строки данных, но пользователи всегда могут видеть сведения или суммированные данные.

Вопрос. Мой источник данных уже имеет определенные роли безопасности (например, роли SQL Server или роли SAP BW). Что такое связь между этими ролями и RLS?
Ответ. Ответ зависит от того, импортируете ли вы данные или используете DirectQuery. Если вы импортируете данные в набор данных Power BI, роли безопасности в источнике данных не используются. В этом случае необходимо определить RLS для применения правил безопасности для пользователей, которые подключаются в Power BI. Если вы используете DirectQuery, используются роли безопасности в источнике данных. Когда пользователь открывает отчет, Power BI отправляет запрос в базовый источник данных, который применяет правила безопасности к данным на основе учетных данных пользователя.

Вопрос. Может ли пользователь принадлежать более одной роли?
Ответ. Пользователь может принадлежать нескольким ролям, а роли являются аддитивными. Например, если пользователь принадлежит к ролям "Продажи" и "Маркетинг", они могут просматривать данные для обеих этих ролей.

Связанный контент

• Ограничение доступа к данным с помощью безопасности на уровне строк (RLS) для Power BI Desktop
• Планирование реализации Power BI: планирование безопасности потребителей
• RLS для встраиваемых сценариев для независимых поставщиков программного обеспечения
• Распространяйте содержимое Power BI внешним гостям с помощью Microsoft Entra B2B

Вопросы? Попробуйте обратиться к сообществу Power BI с вопросами? Участие в разработке идей по улучшению Power BI