Row-Level Security в Power BI: как разграничить доступ к отчётам

В банковском хранилище десятки сейфовых ячеек могут стоять в одной комнате, но ключ клиента открывает только его ячейку. Отчёт Power BI может работать по схожей логике: люди открывают ту же страницу, но видят разные строки данных. За это отвечает Power BI row level security (RLS) — механизм, который ограничивает доступ к данным в зависимости от роли или учётной записи пользователя.

Что такое Row-Level Security в Power BI?

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

Row-level security Power BI работает через роли в Power BI и правила фильтрации. Их создают в Power BI Desktop, а пользователей или группы назначают на соответствующие роли уже в Power BI Service. Когда компания использует Power BI для бизнеса, RLS определяет, какой срез данных получит каждый пользователь после входа.

Как работает RLS в Power BI? Система определяет роль пользователя, применяет соответствующее правило и возвращает только разрешённые строки.

Зачем бизнесу RLS

Когда один дашборд используют руководители, менеджеры и отдельные подразделения, полный доступ к отчётам Power BI нужен не всем. Без RLS приходится или создавать отдельные версии отчёта, или открывать более широкий набор данных, чем нужно конкретному пользователю.

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

Пример: региональные менеджеры видят только свои данные

Проще всего разграничение доступа в Power BI показать на региональной структуре. Компания имеет один отчёт о продажах, но каждому из них доступна только нужная часть данных:

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

Как настроить RLS в 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 даёт неправильный результат из-за конфигурации модели или разрешений:

RLS в Power BI vs безопасность данных в Microsoft Fabric

RLS в Power BI работает на уровне модели данных и определяет, какие её строки доступны пользователю. Microsoft Fabric охватывает больше уровней доступа: отдельно контролируются рабочие пространства, отдельные ресурсы платформы и сами данные.

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

Как IWIS настраивает безопасность данных для клиентов

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