Ограничение доступа к данным модели Power BI
В качестве моделиировщика данных вы настроили RLS, создав одну или несколько ролей. Роль имеет уникальное имя в модели и обычно включает одно или несколько правил. Правила применяют фильтры к таблицам моделей с помощью выражений фильтров на языке DAX.
Замечание
По умолчанию модель данных не имеет ролей. Модель данных без ролей означает, что пользователи (имеющие разрешение на запрос модели данных) имеют доступ ко всем данным модели.
Подсказка
Можно определить роль, которая не содержит правил. В этом случае роль предоставляет доступ ко всем строкам всех таблиц моделей. Эта роль будет подходит для пользователя администратора, которому разрешено просматривать все данные.
Вы можете создавать, проверять и управлять ролями в Power BI Desktop. Для моделей Служб Azure Analysis Services или SQL Server Analysis Services можно создавать, проверять и управлять ролями с помощью SQL Server Data Tools (SSDT).
Вы также можете создавать роли и управлять ими с помощью SQL Server Management Studio (SSMS) или с помощью стороннего средства, например табличного редактора.
Чтобы лучше понять, как RLS ограничивает доступ к данным, просмотрите следующее анимированное изображение.
Применение принципов проектирования схемы звезд
Мы рекомендуем применить принципы проектирования схемы звезд для создания модели, содержащей таблицы измерений и фактов. Обычно для настройки Power BI применяются правила фильтрации таблиц измерений, что позволяет связям модели эффективно распространять эти фильтры на таблицы фактов.
На следующем рисунке показана схема модели данных анализа продаж Adventure Works. В нем показана звёздная схема, состоящая из одной фактографической таблицы под названием Sales. Другие таблицы — это таблицы измерений, которые поддерживают анализ мер продаж по дате, территории продаж, клиенту, торговому посреднику, заказу, продукту и продавцу. Обратите внимание на связи модели, соединяющие все таблицы. Эти связи распространяют фильтры (прямо или косвенно) в таблицу Sales .
Эта модель поддерживает примеры, представленные в этом уроке.
Определение правил
Выражения правил вычисляются в контексте строки. Контекст строки означает, что выражение вычисляется для каждой строки с помощью значений столбцов этой строки. Когда выражение возвращает TRUE, пользователь видит строку.
Подсказка
Дополнительные сведения о контексте строки см. в модуле Добавление вычисляемых таблиц и столбцов в модели Power BI Desktop. Хотя этот модуль описывает добавление модельных расчетов, он включает в себя раздел, вводящий и описывающий контекст строки.
Можно определить правила, которые являются статическими или динамическими.
Статические правила
Статические правила используют выражения DAX, ссылающиеся на константы.
Рассмотрим следующее правило, применяемое к таблице Region, которое ограничивает доступ к данным о продажах в Среднем Западе.
'Region'[Region] = "Midwest"
Ниже описано, как Power BI применяет правило. Оно:
Фильтрует таблицу "Регион ", что приводит к одной видимой строке (для Midwest).
Использует связь модели для распространения фильтра таблицы Регион в таблицу Штат, что приводит к 14 видимым строкам (Средний Запад состоит из 14 штатов).
Использует связь модели для распространения фильтра таблицы State в таблицу Sales, что приводит к отображению тысяч строк (фактов продаж для штатов, принадлежащих среднезападному региону).
Самое простое статическое правило, которое можно создать, ограничивает доступ ко всем строкам таблицы. Рассмотрим следующее правило, применяемое к таблице сведений о продажах (не изображено на схеме модели).
FALSE()
Это правило гарантирует, что пользователи не могут получить доступ к данным таблицы. Это может быть полезно, если продавцы могут видеть агрегированные результаты продаж (из таблицы продаж ), но не сведения о уровне заказа.
Определение статических правил является простым и эффективным. Рекомендуется использовать их, если вам нужно создать только несколько из них, как это может быть в Adventure Works, где есть только шесть регионов США. Однако следует учитывать недостатки: настройка статических правил может включать значительные усилия для создания и настройки. Кроме того, вам потребуется обновить и повторно опубликовать набор данных при подключении новых регионов.
Если существует множество правил для настройки и вы ожидаете добавления новых правил в будущем, рассмотрите возможность создания динамических правил.
Динамические правила
Динамические правила используют определенные функции DAX, возвращающие значения среды (в отличие от констант). Значения среды возвращаются из трех конкретных функций DAX:
ИМЯ ПОЛЬЗОВАТЕЛЯ или USERPRINCIPALNAME — возвращает пользователя, прошедшего проверку подлинности Power BI, в качестве текстового значения.
CUSTOMDATA — возвращает свойство CustomData , переданное в строке подключения. Средства отчетов, отличные от Power BI, которые подключаются к набору данных с помощью строки подключения, могут задать это свойство, например Microsoft Excel.
Замечание
Помните, что функция USERNAME возвращает пользователя в формате DOMAIN\username при использовании в Power BI Desktop. Однако при использовании в службе Power BI он возвращает формат имени участника-пользователя (UPN), например [email protected]. В качестве альтернативы, можно использовать функцию USERPRINCIPALNAME, которая всегда возвращает пользователя в формате имени основного пользователя.
Рассмотрим измененную модель, которая теперь включает (скрытую) таблицу AppUser . Каждая строка таблицы AppUser описывает имя пользователя и регион. Связь модели с таблицей "Регион " распространяет фильтры из таблицы AppUser .
Следующее правило, применяемое к таблице AppUser, ограничивает доступ к данным для региона(ов) аутентифицированного пользователя.
'AppUser'[UserName] = USERPRINCIPALNAME()
Определение динамических правил является простым и эффективным, если в таблице моделей хранятся значения имени пользователя. Они позволяют применять структуру RLS на основе данных. Например, когда продавцы добавляются или удаляются из таблицы AppUser (или назначены разным регионам), этот подход просто работает.
Проверка ролей
При создании ролей важно проверить их, чтобы убедиться, что они применяют правильные фильтры. Для моделей данных, созданных в Power BI Desktop, существует функция View as , которая позволяет просматривать отчет при принудительном применении различных ролей и передавать различные значения имени пользователя.
Настройка сопоставлений ролей
Сопоставления ролей необходимо настроить заранее, когда пользователи получают доступ к содержимому Power BI. Сопоставление ролей подразумевает назначение ролей объектам безопасности Microsoft Entra. Объекты безопасности могут быть учетными записями пользователей или группами безопасности.
Подсказка
По возможности всегда рекомендуется сопоставлять роли с группами безопасности. Таким образом, будет меньше сопоставлений, и вы можете делегировать управление членством в группах администраторам сети.
Для разработанных моделей Power BI Desktop сопоставление ролей обычно выполняется в службе Power BI. Для моделей Служб Azure Analysis Services или SQL Server Analysis Services сопоставление ролей обычно выполняется в SSMS.
Дополнительные сведения о настройке RLS см. в следующем разделе:
Использование единого входа для источников DirectQuery
Если в модели данных есть таблицы DirectQuery и их источник данных поддерживает систему единого входа (SSO), источник данных может применять разрешения на данные. Таким образом, база данных применяет RLS (построчный уровень безопасности), а наборы данных и отчеты Power BI соблюдают безопасность источника данных.
Рассмотрим, что Adventure Works имеет базу данных SQL Azure для своих операций с продажами, которые находятся в том же клиенте, что и Power BI. База данных применяет RLS для управления доступом к строкам в различных таблицах баз данных. Вы можете создать модель DirectQuery, которая подключается к этой базе данных без ролей и опубликовать ее в службе Power BI. При настройке учетных данных источника данных в службе Power BI включите единый вход. Когда потребители отчетов открывают отчеты Power BI, Power BI передает их идентификацию источнику данных. Затем источник данных применяет RLS на основе личности потребителя отчета.
Сведения о RLS базы данных SQL Azure см. в разделе "Безопасность на уровне строк".
Замечание
Вычисляемые таблицы и вычисляемые столбцы, которые ссылаются на таблицу DirectQuery из источника данных с аутентификацией единого входа, не поддерживаются в службе Power BI.
Дополнительные сведения о источниках данных, поддерживающих единый вход, см. в разделе "Единый вход" для источников DirectQuery.