RLS на SSAS Tabular: 6 production-паттернов

Территориальный RLS: менеджер видит свой регион

Самый частый кейс. В dim_employee есть колонки user_principal_name и region_id. Правило: менеджер видит строки, где regions совпадает с его собственным.

Модель: таблица dim_employee (user_principal_name, region_id, employee_name, role).

DAX-фильтр на таблице dim_region:

[region_id] = LOOKUPVALUE(
    dim_employee[region_id],
    dim_employee[user_principal_name], USERPRINCIPALNAME()
)

Фильтр применяется к dim_region. Через связь dim_region → fact_sales он автоматически пробрасывается в факты. Пользователь видит только свои транзакции, отчёты работают как обычно, никаких изменений в DAX-мер не нужно.

Когда не работает: если один сотрудник отвечает за несколько регионов. Для этого — паттерн 03 (dynamic через bridge).

Иерархический RLS: руководитель видит всю свою вертикаль

Кейс посложнее: Иванов — директор региона. Он должен видеть продажи всех подчинённых (менеджеров, агентов, точек продаж). В оргструктуре может быть произвольная глубина.

Модель: dim_employee (employee_id, manager_id, user_principal_name, full_path) + на стороне SQL/ETL считаем path через рекурсивный CTE: для каждого сотрудника хранится цепочка вида |1|3|17|42| (ID всех руководителей вверх по иерархии).

DAX-фильтр на dim_employee:

VAR _current_user_id =
    LOOKUPVALUE(
        dim_employee[employee_id],
        dim_employee[user_principal_name], USERPRINCIPALNAME()
    )
RETURN
    CONTAINSSTRING(
        dim_employee[full_path],
        "|" & _current_user_id & "|"
    )
    || dim_employee[employee_id] = _current_user_id

Логика: пользователь видит строку, если в её full_path встречается его собственный ID (то есть он в цепочке руководителей этой строки), либо если это его собственная запись. Разделители |...| нужны, чтобы ID «1» не матчился с «10» или «100».

Альтернатива — PATH/PATHCONTAINS (встроенные функции DAX для parent-child иерархии). Но на больших таблицах (>100 тыс. сотрудников) строковое сравнение через CONTAINSSTRING работает быстрее.

Dynamic RLS через bridge-таблицу

Сотрудник может отвечать за несколько регионов, стран или товарных категорий. Жёсткая 1-to-1 связь не работает. Решение — отдельная bridge-таблица, которая сопоставляет пользователей и объекты доступа.

Модель:

dim_employee  ──┐
                │
                ▼
        rls_user_region  (user_principal_name, region_id)
                │
                ▼
        dim_region
                │
                ▼
        fact_sales

Таблица rls_user_region скрыта от пользователей (hidden=true). Заполняется из ETL по данным AD или CRM: один логин — несколько строк с разными region_id.

DAX-фильтр на dim_region:

dim_region[region_id] IN
    CALCULATETABLE(
        VALUES(rls_user_region[region_id]),
        rls_user_region[user_principal_name] = USERPRINCIPALNAME()
    )

Или через TREATAS (быстрее на больших объёмах):

TREATAS(
    CALCULATETABLE(
        VALUES(rls_user_region[region_id]),
        rls_user_region[user_principal_name] = USERPRINCIPALNAME()
    ),
    dim_region[region_id]
)

Добавили менеджера к новому региону — добавили строку в bridge. Пересборка модели не нужна, права обновляются при следующем входе.

Object-Level Security: скрыть колонку целиком

RLS прячет строки. OLS прячет таблицы или колонки полностью. Типичный кейс — колонка salary в dim_employee должна быть видна только HR и финблоку.

В SSAS Tabular 2017+ OLS настраивается через XMLA или SSDT: для каждой роли указывается MetadataPermission=None для конкретной колонки. В Power BI Desktop нативной UI для OLS нет — настраивается через Tabular Editor.

Пример (Tabular Editor, C#-скрипт):

// Роль AllEmployees — все видят employee, но не salary
Model.Roles["AllEmployees"].TablePermissions["dim_employee"]
    .ColumnPermissions["salary"].MetadataPermission
    = MetadataPermission.None;

// Роль HR — видят всё
Model.Roles["HR"].TablePermissions["dim_employee"]
    .ColumnPermissions["salary"].MetadataPermission
    = MetadataPermission.Default;

Пользователь в роли AllEmployees не увидит колонку salary вообще: её не будет в панели Fields, её нельзя использовать в мерах. SUMMARIZECOLUMNS с этой колонкой вернёт ошибку доступа. Защита жёсткая, но требует аккуратного тестирования: любая мера, использующая скрытую колонку, сломается для пользователей без прав.

RLS + агрегационные таблицы: держим согласованность

Если в модели есть aggregation tables (см. P13 про рефакторинг), RLS должен применяться и к ним. Иначе пользователь увидит суммы по регионам, которых формально не видит в детализации — типичная дырка.

Правильно: агрегационная таблица agg_sales_monthly содержит region_id, и RLS-фильтр применяется на dim_region, который связан и с fact_sales, и с agg_sales_monthly. Тогда при любом запросе — идёт ли он в агрегат или в факт — фильтр срабатывает одинаково.

Проверочный DAX-запрос:

// Под ролью Region_North (регион-ID 1)
// эти два числа должны быть равны:

// 1. Из детализации (fact_sales)
SUMX(fact_sales, fact_sales[revenue])

// 2. Из агрегата (agg_sales_monthly)
SUMX(agg_sales_monthly, agg_sales_monthly[revenue])

Если числа разные — или RLS не распространился на агрегат, или в агрегате данные устарели. Оба случая — баг, нужно чинить.

Impersonation: «посмотреть как пользователь X»

При отладке RLS нужно уметь проверить, что видит конкретный пользователь. В Power BI Desktop есть «View as role», но это проверка роли целиком. Для проверки «как конкретный AD-пользователь» есть EffectiveUserName.

В DAX Studio (подключение к SSAS):

Connection properties →
    Roles: Region_Sales
    Effective Username: maria.petrova@company.com

// Далее выполняете любой DAX-запрос — будете
// видеть результат как у Марии Петровой

Это требует, чтобы BI-админ был в группе Server Admin на SSAS (иначе impersonation запрещён). На продакшне используйте с осторожностью: impersonation логгируется, но имеет смысл согласовать с ИБ порядок применения.

Альтернатива — отдельная admin-роль с фильтром «TRUE()» (видит всё). Удобнее для повседневного дев-мониторинга, менее подозрительно для ИБ.