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 спочатку складає матрицю доступу, а вже під неї визначає статичні або динамічні правила та перевіряє їх разом із правами робочого простору.