Один отчёт — но менеджер Юга должен видеть только Юг, менеджер Запада — только Запад, а коммерческий директор — всё. Заводить три копии отчёта — тупик. Правильно — Row-Level Security (RLS): фильтр по строкам, который зависит от того, кто открыл отчёт. Разбираем по документации Microsoft.
Учебный набор: Продажи, Регионы[Регион, МенеджерEmail], Календарь. Задача — каждый менеджер видит только свои регионы, руководитель — все.
Что такое RLS
RLS — это роли, в каждой из которых заданы DAX-фильтры на таблицы. Когда пользователь открывает отчёт, Power BI смотрит, в какие роли он входит, и применяет их фильтры как обычный контекст фильтра — поверх всех мер и визуалов. Пользователь даже не знает, что видит срез: для него это «весь отчёт».
RLS не прячет кнопки или страницы — он урезает данные на уровне модели. Мера [Выручка] сама вернёт только то, что роль разрешила видеть. Поэтому обойти RLS через другой визуал или экспорт нельзя.
Статический RLS
Самый простой вариант: роль с жёстко прописанным фильтром.
- В Power BI Desktop: Моделирование → Управление ролями.
- Создаём роль «Юг», на таблице
Регионызадаём фильтр:
[Регион] = "Юг"- Публикуем, в Power BI Service в наборе данных → Безопасность добавляем в роль «Юг» нужных пользователей по email.
Минус очевиден: ролей столько, сколько регионов, и каждого человека надо вручную раскидать. На пяти регионах терпимо, на пятидесяти — боль.
Динамический RLS
Идея: одна роль на всех, а кто что видит — определяет таблица соответствий «пользователь → регион». Фильтр использует функцию USERPRINCIPALNAME() — она возвращает email вошедшего.
В справочнике Регионы есть столбец МенеджерEmail. Создаём одну роль (например, «Менеджеры») с фильтром на Регионы:
[МенеджерEmail] = USERPRINCIPALNAME ()Теперь вошедший видит только те регионы, где он указан менеджером. Добавили нового сотрудника — просто дописали строку в справочник, роль трогать не нужно.
USERPRINCIPALNAME() подставляет email текущего пользователя прямо в фильтр. Связь от Регионы к Продажи разносит этот фильтр на факты. Управление доступом превращается в строки таблицы, а не в десятки ролей.
Когда доступов «много-ко-многим»
Менеджер отвечает за несколько регионов, а регион ведут несколько менеджеров — прямого столбца не хватает. Тогда заводят отдельную таблицу-мост ДоступМенеджеров[Email, Регион] и фильтруют её:
[Email] = USERPRINCIPALNAME ()Через связь ДоступМенеджеров → Регионы → Продажи доступ корректно расходится на всё. Это та же логика мостовых таблиц из pro-курса, но в роли механизма безопасности.
Проверка ролей
Не публикуйте RLS вслепую. В Desktop: Моделирование → Просмотр как роли — выбираете роль (и при динамическом RLS вводите конкретный email через «Другой пользователь») и видите отчёт его глазами. Так ловятся пустые экраны и протечки данных до релиза.
- Направление связи. Если фильтр с
Регионыне доходит доПродажи(однонаправленная связь «не туда»), менеджер увидит либо всё, либо ничего. Проверьте схему. - Роль не назначена в Service. Фильтр в Desktop есть, но в Service пользователя не добавили в роль — он упрётся в ошибку доступа.
- Админ и владелец. Владелец семантической модели и администратор рабочей области (workspace) RLS не ограничивает — тестируйте под обычным пользователем.
- Двунаправленные связи в комбинации с RLS дают неожиданные протечки. Включайте bidirectional осознанно.
RLS и OLS
RLS режет строки. Если нужно скрыть столбец целиком (например, оклады) — это другой механизм, Object-Level Security (OLS), настраивается во внешних инструментах (Tabular Editor). RLS и OLS дополняют друг друга.
Что дальше
Доступы закрыли. Дальше — инкрементальное обновление: как обновлять только свежие данные, а не перегружать миллиарды строк целиком. Следующий урок.