Что делает RLS в Power BI
RLS — это набор правил в семантической модели Power BI, которые фильтруют строки таблиц в зависимости от того, кто открыл отчёт. Правило записывается как фильтр на языке DAX и привязывается к роли. Пользователей или группы назначают на роли в службе Power BI, и при каждом открытии отчёта модель применяет фильтр их роли ко всем визуалам.
Для международного fashion-бренда это решает типичную задачу. Отчёт по продажам, остаткам и марже нужен всем рынкам, но руководитель в одной стране не должен видеть цифры соседней. Без RLS приходится делать копию отчёта на каждый рынок, и через полгода эти копии расходятся по мерам, визуалам и определениям показателей. С RLS есть один отчёт, одна модель и одни формулы, а различается только набор строк.
Фильтр роли применяется на уровне модели, а не отдельной страницы. Поэтому он действует везде, где пользователь обращается к данным: в отчёте, в приложении Power BI, в сводной таблице через «Анализ в Excel». Обойти его, сняв фильтр в визуале или выгрузив данные, пользователь с правами просмотра не может.
Важно понимать, что RLS фильтрует строки, а не скрывает таблицы или столбцы. Пользователь с ролью рынка «Польша» увидит все столбцы таблицы продаж, но только польские строки. Если нужно спрятать целый столбец, например себестоимость, для этого есть отдельный механизм — безопасность на уровне объектов (OLS). Его обычно настраивают через внешние инструменты вроде Tabular Editor, и он часто дополняет RLS в отчётах с финансовыми данными.
Статический и динамический RLS для рынков
Статический RLS — это отдельная роль на каждый рынок с жёстко заданным фильтром. Роль «Польша» фильтрует справочник рынков по коду PL, роль «Чехия» — по коду CZ. Такой вариант быстро настраивается и хорошо подходит, когда рынков немного и состав пользователей меняется редко.
-- Роль «Польша»
[MarketCode] = "PL"
-- Роль «Чехия»
[MarketCode] = "CZ"Динамический RLS устроен иначе: роль одна, а доступ описан в таблице соответствия «пользователь — рынок». Фильтр роли сравнивает учётную запись того, кто открыл отчёт, с этой таблицей через функцию USERPRINCIPALNAME(). В службе Power BI она возвращает адрес входа пользователя, обычно его корпоративный e-mail. Новому сотруднику достаточно добавить строку в таблицу доступа, модель менять не нужно.
VAR UserMarkets =
CALCULATETABLE (
VALUES ( UserAccess[MarketCode] ),
UserAccess[UserEmail] = USERPRINCIPALNAME ()
)
RETURN
"ALL" IN UserMarkets
|| Market[MarketCode] IN UserMarketsСтрока с кодом ALL в таблице доступа даёт пользователю все рынки: так удобно открывать отчёт для региональной команды или головного офиса без отдельной роли. Я предпочитаю несвязанную таблицу доступа, потому что она не требует двунаправленных связей в модели и её легко проверить глазами. Таблицу доступа удобно вести в одном месте, например в отдельной таблице источника, и назначить за неё ответственного: тогда вопрос «кто что видит» решается без разработчика отчёта.
| Признак | Статический RLS | Динамический RLS |
|---|---|---|
| Число ролей | Одна на каждый рынок | Одна на все рынки |
| Где хранится доступ | В фильтрах ролей | В таблице «пользователь — рынок» |
| Новый сотрудник | Назначить на роль в службе | Добавить строку в таблицу |
| Новый рынок | Создать роль и опубликовать модель | Добавить строки в таблицу |
| Когда подходит | Мало рынков, стабильный состав | Много рынков или частые изменения |
Роли рынков в Power BI по шагам
Перед настройкой ролей проверьте модель. RLS работает через связи: фильтр на справочнике рынков должен доходить до таблиц фактов — продаж, остатков, плана. Если таблица остатков не связана со справочником рынков, фильтр роли на неё не подействует, и пользователь увидит остатки всех стран. Это самая частая ошибка, которую я встречаю при проверке чужих отчётов.
- В Power BI Desktop откройте вкладку «Моделирование» и выберите «Управление ролями».
- Создайте роль, например «Рынок» для динамического варианта или «Польша» для статического.
- Выберите таблицу, на которую ставится фильтр, — справочник рынков, а не таблицу продаж.
- Задайте фильтр в табличном редакторе или переключитесь на редактор DAX и вставьте выражение.
- Сохраните роли и опубликуйте отчёт в рабочую область службы Power BI.
- В службе откройте меню семантической модели, выберите «Безопасность» и добавьте в роль пользователей или группы безопасности.
На роли лучше назначать группы, а не отдельных людей. Когда сотрудник меняет рынок или уходит, доступ меняется в одном месте — в группе, и никто не забывает убрать его из отчёта. Для динамического RLS роль назначают одной общей группе всех пользователей отчёта, а конкретный рынок определяет таблица доступа.
RLS работает и в Power BI Report Server, если отчёты публикуются на собственном сервере компании. Логика ролей та же, но пользователей назначают в настройках отчёта на сервере, а USERPRINCIPALNAME() возвращает учётную запись домена.
Как проверить RLS в Power BI
Проверять RLS нужно до того, как отчёт увидят пользователи, и после каждого изменения модели. В Power BI Desktop откройте «Моделирование» → «Просмотреть как» и выберите роль: отчёт покажет данные так, как их увидит пользователь этой роли. Для динамического RLS отметьте ещё «Другой пользователь» и введите e-mail из таблицы доступа — иначе USERPRINCIPALNAME() вернёт вашу собственную учётную запись.
В службе Power BI то же самое делается через пункт «Проверить как роль» в настройках безопасности семантической модели. Здесь я проверяю три сценария: пользователь с одним рынком, пользователь с несколькими рынками и пользователь, которого нет в таблице доступа. Последний должен видеть пустой отчёт, а не все данные.
Помните и об ограничении, которое часто удивляет владельцев отчётов: RLS действует только для пользователей с правами просмотра. Администраторы, участники и соавторы рабочей области с правами на изменение видят все данные независимо от ролей. Поэтому рыночным командам отчёт лучше давать через приложение Power BI или с ролью «Средство просмотра» в рабочей области.
Типичные ошибки RLS в отчётах для рынков
Большинство проблем с безопасностью на уровне строк я вижу не в формулах ролей, а в том, что вокруг них. Вот что стоит проверить в любом отчёте с RLS перед тем, как открыть его рынкам:
- Фильтр стоит на таблице фактов, а не на справочнике. Тогда он ограничивает только одну таблицу, а план, остатки и другие факты остаются открытыми. Фильтр ставится на справочник рынков, а таблицы фактов получают его через связи.
- Не все таблицы фактов связаны со справочником рынков. Новая таблица, добавленная через полгода после запуска, часто остаётся без связи и без защиты.
- Таблица доступа живёт отдельно от обновления модели. Если её ведут в Excel или SharePoint, изменение вступит в силу только после обновления семантической модели.
- Пользователи рынков получили права на изменение рабочей области, и RLS на них не действует.
- RLS проверили только в Power BI Desktop под своей учётной записью и не проверили в службе под реальными пользователями.
Отдельная ловушка — доли от общего итога. Если в отчёте есть показатель «доля рынка в общих продажах бренда», под RLS он покажет 100%, потому что пользователь видит только свои строки. Такие меры нужно либо убрать из отчёта для рынков, либо считать общий итог в отдельной агрегированной таблице, на которую RLS не распространяется.