Ограничение доступа к объектам модели Power BI
Вы как разработчик моделей данных можете рассмотреть возможность ограничить доступ пользователей к объектам модели Power BI. Безопасность на уровне объектов (OLS) позволяет ограничить доступ к определенным таблицам и столбцам и их метаданным. Как правило, OLS применяется для защиты объектов, в которых хранятся конфиденциальные данные (например, персональные данные сотрудников).
Когда Power BI принудительно применяет OLS, обеспечивается не только ограничение доступа к таблицам и столбцам, но и защита метаданных. При защите метаданных невозможно получить сведения о защищенных таблицах и столбцах с помощью динамических административных представлений (DMV).
Внимание
В табличных моделях можно скрывать таблицы и столбцы (и другие объекты) с помощью перспективы. Перспектива определяет доступные для просмотра подмножества объектов модели, чтобы сосредоточиться на авторах отчетов. Перспективы призваны упростить модели, помогая авторам отчетов находить интересующие их ресурсы. Однако перспективы не являются функцией безопасности, поскольку они не защищают объекты. Пользователь по-прежнему может запросить таблицу или столбец, даже если он ему не виден.
Рассмотрим пример с компанией Adventure Works. В этой организации есть таблица измерения хранилища данных с именем DimEmployee. В этой таблице имеются столбцы, в которых хранятся сведения об имени сотрудника, его телефоне, адресе электронной почты и заработной плате. Обычным пользователям отчетов должны быть доступны имя сотрудника и контактные данные, однако они не должны видеть данные о заработной плате, поскольку эти сведения доступны только старшим сотрудникам отдела кадров. Таким образом, разработчик моделей данных использовал OLS для предоставления доступа к столбцу со сведениями о заработной плате только определенным сотрудникам отдела кадров.
OLS — это функция, унаследованная от Azure Analysis Services (AAS) и SQL Server Analysis Services (SSAS). Она доступна в Power BI Premium для обеспечения обратной совместимости моделей, перенесенных в Power BI. По этой причине невозможно полностью настроить OLS в Power BI Desktop.
Настройка OLS
Чтобы настроить OLS, сначала создайте роли. Роли можно создать в Power BI Desktop так же, как при настройке RLS. Затем необходимо добавить правила OLS в роли. Эта возможность не поддерживается в Power BI Desktop, поэтому вам потребуется использовать другой подход.
Для добавления правил OLS в модель Power BI Desktop используется конечная точка XML для аналитики (XMLA). Конечные точки XMLA доступны в Power BI Premium и предоставляют доступ к подсистеме Analysis Services в службе Power BI. Конечная точка чтения и записи поддерживает управление наборами данных, управление жизненным циклом приложений, расширенное моделирование данных и многое другое. Api с поддержкой конечной точки XMLA можно использовать для сценариев, таких как язык сценариев табличных моделей (TMSL) или модуль SqlServer PowerShell. Или можно использовать клиентское средство, например SSMS. Существуют и сторонние альтернативы, такие как Tabular Editor. Это инструмент для создания, обслуживания и контроля моделей с открытым кодом.
По умолчанию все таблицы и столбцы модели не ограничены. Вы можете задать для них значение Нет или Чтение. Если задано значение Нет, пользователи, связанные с ролью, не могут получить доступ к объекту. Если задано значение Чтение, пользователи, связанные с ролью, могут получить доступ к объекту. При ограничении определенных столбцов убедитесь, что для таблицы не задано значение Нет.
Добавив правила OLS, можно опубликовать модель в службе Power BI. Используйте тот же процесс для RLS для сопоставления учетных записей и групп безопасности с ролями.
Рекомендации
В отчете Power BI, если у пользователя нет разрешения на доступ к таблице или столбцу, отобразится сообщение об ошибке. В нем будет указано, что объект не существует.
Тщательно продумайте, является ли OLS правильным решением для вашего проекта. Когда пользователь открывает Power BI отчет, который запрашивает ограниченный объект (для него), сообщение об ошибке может запутать пользователя и оттолкнуть его. Для них это выглядит так, будто отчет не работает. Лучше всего создать отдельный набор моделей или отчетов в соответствии с требованиями различных пользователей отчетов.
Ограничения
Существует ряд ограничений, которые следует учитывать при реализации OLS.
Нельзя использовать и RLS, и OLS в одной роли. Если необходимо применить RLS и OLS в одной модели, создайте отдельные роли для каждого типа. Кроме того, невозможно задать безопасность на уровне таблицы, если она нарушает цепочку связей. Например, при наличии связей между таблицами A и B и B и C невозможно защитить таблицу B. Если таблица B защищена, запрос к таблице A не удастся передать между таблицами A и B и B и C. В этом случае можно настроить отдельную связь между таблицами A и C.
Однако связи модели, ссылающиеся на защищенный столбец, будут работать, при условии, что таблица столбца не защищена.
Наконец, хотя невозможно защитить меры, мера, которая ссылается на защищенные объекты, автоматически ограничивается.
Дополнительные сведения см. в статье Безопасность на уровне объектов.