Как сделать так, чтобы один отчёт Power BI показывал разным пользователям разные данные: статические и динамические роли, уровни разрешений и типичные ошибки настройки.
В банковском хранилище десятки сейфовых ячеек могут стоять в одной комнате, но ключ клиента открывает только его ячейку. Отчёт Power BI может работать по схожей логике: люди открывают ту же страницу, но видят разные строки данных. За это отвечает Power BI row level security (RLS) — механизм, который ограничивает доступ к данным в зависимости от роли или учётной записи пользователя.
Если коротко ответить на вопрос, что такое RLS в Power BI, это механизм, который определяет, какие строки модели данных доступны конкретному пользователю. Сам отчёт при этом может быть один: региональный менеджер увидит продажи своего региона, а руководитель — сводные показатели.
Row-level security Power BI работает через роли в Power BI и правила фильтрации. Их создают в Power BI Desktop, а пользователей или группы назначают на соответствующие роли уже в Power BI Service. Когда компания использует Power BI для бизнеса, RLS определяет, какой срез данных получит каждый пользователь после входа.
Как работает RLS в Power BI? Система определяет роль пользователя, применяет соответствующее правило и возвращает только разрешённые строки.
Когда один дашборд используют руководители, менеджеры и отдельные подразделения, полный доступ к отчётам Power BI нужен не всем. Без RLS приходится или создавать отдельные версии отчёта, или открывать более широкий набор данных, чем нужно конкретному пользователю.
RLS позволяет не размножать отдельные версии одного отчёта только из-за разных прав пользователей. Данные остаются в одной модели, а доступный срез определяется ролью. Права доступа Power BI зависят не только от RLS. Отдельно настраиваются права в рабочем пространстве Power BI и доступ к самому отчёту: RLS не заменяет эти уровни разрешений. Особенно важно ограничение доступа к данным в Power BI, когда с одним отчётом работают разные подразделения. Продажам могут быть нужны показатели клиентов и регионов, финансам — маржинальность, а руководству — общая картина. Давать всем одинаковый доступ в такой ситуации просто нет смысла.
Проще всего разграничение доступа в Power BI показать на региональной структуре. Компания имеет один отчёт о продажах, но каждому из них доступна только нужная часть данных:
| Пользователь | Что видит в отчёте |
|---|---|
| Менеджер региона «Юг» | Продажи и KPI своего региона |
| Менеджер региона «Запад» | Продажи и KPI своего региона |
| Руководитель отдела продаж | Сводные данные по регионам |
| Финансовый директор | Данные, предусмотренные его ролью |
В результате аналитик поддерживает один отчёт, а изменение цифр или структуры визуализации не требует синхронизировать несколько его копий. Именно поэтому во время внедрения бизнес-аналитики на базе Power BI логику доступа стоит продумывать вместе с моделью данных и ролями пользователей.
Чтобы понять, как настроить RLS в Power BI, достаточно пройти несколько основных шагов:
В Power BI есть несколько уровней доступа. Power BI workspace permissions определяют права пользователя в рабочем пространстве, а Power BI report permissions — доступ к конкретному отчёту. RLS работает на уровне модели данных, но результат зависит и от роли пользователя в рабочем пространстве. Ограничения RLS действуют для Viewer, тогда как Admin, Member и Contributor имеют более широкие права доступа.
Static RLS в Power BI использует фиксированные правила. Например, для роли «Юг» можно задать условие, которое оставляет только строки этого региона, а затем назначить нужных пользователей на роль в Power BI Service.
Такой вариант удобен, когда сегментов немного, правила стабильны и их легко поддерживать. Если структура доступа часто меняется, количество статических ролей и ручных назначений быстро растёт.
В Dynamic RLS в Power BI правило зависит от того, кто именно открыл отчёт. Один из распространённых вариантов — функция USERPRINCIPALNAME(), которая возвращает идентификатор пользователя (UPN) в Power BI Service, и отдельная таблица соответствия, например «пользователь → регион».
На этом и строится dynamic row level security в Power BI: отдельную роль для каждого региона или сотрудника создавать не нужно — нужный срез определяется по данным пользователя.
Если свести static vs dynamic RLS к практической разнице, она заключается в способе определения доступа:
| Критерий | Статические роли | Динамические роли |
|---|---|---|
| Правило | Фиксированное для роли | Зависит от идентичности пользователя |
| Изменения доступа | Требуют работы с ролями или их участниками | Могут управляться через таблицу соответствия |
| Масштабирование | Удобное для простой стабильной структуры | Удобнее для изменяющейся структуры доступа |
Если данные о правах доступа уже хранятся в корпоративных системах, фильтрацию данных по пользователю в Power BI не обязательно поддерживать вручную. Например, в Data Platform для бизнеса таблицу соответствия «пользователь → регион» можно обновлять вместе с другими корпоративными справочниками.
Чаще всего RLS даёт неправильный результат из-за конфигурации модели или разрешений:
RLS в Power BI работает на уровне модели данных и определяет, какие её строки доступны пользователю. Microsoft Fabric охватывает больше уровней доступа: отдельно контролируются рабочие пространства, отдельные ресурсы платформы и сами данные.
| Критерий | Power BI RLS | Безопасность в Microsoft Fabric |
|---|---|---|
| Уровень | Модель данных | Рабочие пространства, отдельные ресурсы и данные |
| Задача | Ограничить строки, доступные через модель | Управлять доступом к ресурсам и данным в Fabric |
| Пример | Менеджер видит свой регион в отчёте | Команда получает доступ только к нужным ресурсам платформы |
В Fabric RLS отвечает за фильтрацию строк в модели данных. Доступ к рабочим пространствам, отдельным ресурсам платформы и другим уровням данных настраивается отдельно.
В двух компаниях с одинаковым количеством пользователей схема RLS может быть совершенно разной. В одной достаточно нескольких стабильных ролей по регионам, в другой доступ зависит от должности, подразделения, клиента или нескольких условий одновременно. Поэтому команда IWIS сначала составляет матрицу доступа, а уже под неё определяет статические или динамические правила и проверяет их вместе с правами рабочего пространства.
Если в системе отчётности Power BI несколько групп пользователей должны видеть разные данные, IWIS поможет построить схему доступа и правильно настроить её через RLS. Запишитесь на бесплатную консультацию, где разберём вашу структуру пользователей и отчётов и определим, как организовать доступ без дублирования дашбордов и лишнего ручного администрирования.
Записаться на консультацию
RLS ограничивает доступ к отдельным строкам модели данных в зависимости от роли пользователя. Поэтому один и тот же отчёт может показывать разные данные разным людям.
Создайте RLS-роль, задайте правило фильтрации, протестируйте его, опубликуйте модель и назначьте пользователей или группы на роль в Power BI Service. Отдельно проверьте их права в рабочем пространстве и доступ к отчёту.
В статическом RLS правило фильтрации закреплено за ролью. В динамическом оно может изменяться в зависимости от пользователя, например через USERPRINCIPALNAME() и таблицу соответствия.
Для этого используют RLS Power BI: правила модели определяют, какие данные увидит пользователь после входа.
В Power BI Desktop используйте View as, чтобы проверить отчёт от имени роли. После публикации роль также можно протестировать в Power BI Service.
Типичные ошибки: ошибка в DAX-фильтре, некорректно назначенные роли рабочего пространства, устаревшая таблица соответствия и попытка заменить RLS обычными фильтрами в отчёте.
DAX отвечает за расчёты внутри модели...
Читать далее DAX формулы в Power BI: практический гайд
