Ограничение доступа к данным модели Power BI
Вы как разработчик моделей данных настроили безопасность на уровне строк, создав одну или несколько ролей. У роли есть уникальное имя в модели, и оно обычно включает одно или несколько правил. Правила применяют фильтры к таблицам моделей с помощью выражений анализа данных (DAX).
Примечание.
По умолчанию у модели данных нет ролей. Модель данных без ролей означает, что пользователи (имеющие разрешение на запрос модели данных) имеют доступ ко всем данным модели.
Совет
Можно определить роль, которая не содержит правил. В этом случае роль предоставляет доступ ко всем строкам всех таблиц модели. Эта роль подходит для пользователя администратора, которому разрешено просматривать все данные.
Вы можете создавать, проверять роли и управлять ими в Power BI Desktop. Для моделей Microsoft 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, которая ограничивает доступ к данным продажами в Midwest.
'Region'[Region] = "Midwest"
Ниже описано, как Power BI применяет правило. Оно делает следующее.
Фильтрует таблицу Region, в результате чего отображается одна видимая строка (для Midwest).
Использует связь модели для распространения фильтра таблицы Region в таблицу State, что приводит к 14 видимым строкам (регион Midwest состоит из 14 штатов).
Использует связь модели для распространения фильтра таблицы State в таблицу Sales, что приводит к тысячам видимых строк (факты продаж для штатов, относящихся к региону Midwest).
Самое простое статическое правило, которое можно создать, ограничивает доступ ко всем строкам таблицы. Рассмотрим следующее правило, применяемое к таблице Sales Details (Сведения о продажах) (не показано на схеме модели).
FALSE()
Это правило гарантирует, что пользователи не могут получить доступ к данным таблицы. Это может быть полезно, если продавцам разрешено просматривать агрегированные результаты продаж (из таблицы Sales), но не сведения на уровне заказа.
Использовать статические правила — это просто и эффективно. Рекомендуем их использовать, если вам нужно создать небольшое количество правил, как, например, в случае Adventure Works, где всего шесть регионов США. Но следует учитывать и недостатки: настройка статических правил может требовать значительных усилий по созданию и настройке. Кроме того, вам потребуется обновить и повторно опубликовать набор данных при подключении новых регионов.
Если вам нужно настроить множество правил и вы ожидаете, что новые правила будут добавлены и в будущем, рассмотрите возможность использования динамических правил.
Динамические правила
Динамические правила используют определенные функции DAX, возвращающие значения среды (в отличие от констант). Значения среды возвращаются из трех конкретных функций DAX:
USERNAME или USERPRINCIPALNAME — возвращает пользователя Power BI, прошедшего проверку подлинности, в виде текстового значения.
CUSTOMDATA — возвращает содержимое свойства CustomData в строке подключения. Средства создания отчетов, отличные от Power BI, которые подключаются к набору данных с помощью строки подключения, могут задавать это свойство (например, Microsoft Excel).
Примечание.
Помните, что при использовании в Power BI Desktop функция USERNAME возвращает пользователя в формате ДОМЕН\имя_пользователя. Однако при использовании в службе Power BI она использует формат имени субъекта-пользователя (UPN), например username@adventureworks.com. Кроме того, можно использовать функцию USERPRINCIPALNAME, которая всегда возвращает пользователя в формате имени субъекта-пользователя.
Рассмотрим измененную модель, которая теперь включает (скрытую) таблицу AppUser. Каждая строка таблицы AppUser описывает имя пользователя и регион. Связь модели с таблицей Region распространяет фильтры из таблицы AppUser.
Следующее правило, применяемое к таблице AppUser, ограничивает доступ к данным регионами пользователя, прошедшего проверку подлинности.
'AppUser'[UserName] = USERPRINCIPALNAME()
Определение динамических правил — это простой и эффективный способ, если в таблице модели хранятся значения имени пользователя. Они позволяют применять структуру безопасности на уровне строк на основе данных. Например, если продавцы добавляются в таблицу AppUser или удаляются из нее (или назначаются разным регионам), этот подход к проектированию просто работает.
Проверка ролей
При создании ролей важно проверить их, чтобы убедиться, что они применяют правильные фильтры. Для моделей данных, созданных в Power BI Desktop, есть функция Просмотреть как, которая позволяет просматривать отчет при принудительном применении различных ролей и передаче различных значений имени пользователя.
Настройка сопоставления ролей
Сопоставления ролей необходимо настроить заранее для пользователей, обращающихся к содержимому Power BI. Сопоставление ролей включает назначение объектам безопасности Microsoft Entra ролям. Объектами безопасности могут быть учетные записи пользователей или группы безопасности.
Совет
По возможности рекомендуется сопоставить роли с группами безопасности. Таким образом, сопоставлений будет меньше, и вы сможете делегировать управление членством в группах администраторам сети.
Для моделей, разработанных в Power BI Desktop, сопоставление ролей обычно выполняется в службе Power BI. Для моделей Azure Analysis Services ил SQL Server Analysis Services сопоставление ролей обычно выполняется в SSMS.
Для получения дополнительных сведений о настройке RLS смотрите следующие ресурсы:
Row-level security (RLS) with Power BI (Безопасность на уровне строк (RLS) в Power BI)
Руководство по безопасности на уровне строк (RLS) в Power BI Desktop
Единый вход для источников DirectQuery
Если в модели данных есть таблицы DirectQuery и их источник данных поддерживают единый вход, источник данных может применять разрешения данных. Таким образом, база данных принудительно применяет 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.