Руководство по безопасности на уровне строк (RLS) в Power BI Desktop

Эта статья предназначена для моделирователя данных, работающего с Power BI Desktop. В нем описаны рекомендации по проектированию для обеспечения безопасности на уровне строк (RLS) в моделях данных.

Важно понимать строки таблиц RLS. Их нельзя настроить для ограничения доступа к объектам модели, включая таблицы, столбцы или меры.

Примечание.

В этой статье не описывается RLS или как его настроить. Дополнительные сведения см. в разделе "Ограничение доступа к данным с помощью безопасности на уровне строк" (RLS) для Power BI Desktop.

Кроме того, он не охватывает принудительное применение RLS в динамических подключениях к внешним размещенным моделям со службами Azure Analysis Services или SQL Server Analysis Services. В таких случаях RLS применяется службами Analysis Services. При подключении Power BI с помощью единого входа службы Analysis Services будет применять RLS (если учетная запись не имеет прав администратора).

Создание ролей

Можно создать несколько ролей. При рассмотрении потребностей в разрешении для одного пользователя отчета старайтесь создать одну роль, которая предоставляет все эти разрешения, а не проект, в котором пользователь отчета будет членом нескольких ролей. Это связано с тем, что пользователь отчета может сопоставляться с несколькими ролями, напрямую с помощью учетной записи пользователя или косвенного членства в группах безопасности. Несколько сопоставлений ролей могут привести к непредвиденным результатам.

Когда пользователю отчета назначено несколько ролей, фильтры RLS становятся аддитивными. Это означает, что пользователи отчетов могут видеть строки таблицы, представляющие объединение этих фильтров. Более того, в некоторых сценариях невозможно гарантировать, что пользователь отчета не видит строк в таблице. Таким образом, в отличие от разрешений, применяемых к объектам базы данных SQL Server (и другим моделям разрешений), принцип "когда-то отказано в отказе" не применяется.

Рассмотрим модель с двумя ролями: первая роль с именем "Рабочие" ограничивает доступ ко всем строкам таблицы Payroll с помощью следующего выражения правила:

FALSE()

Примечание.

Правило не вернет строк таблицы, когда его выражение вычисляется FALSE.

Тем не менее, вторая роль с именем " Менеджеры" позволяет получить доступ ко всем строкам таблицы Payroll с помощью следующего выражения правила:

TRUE()

Обратите внимание: если пользователь отчета сопоставляется с обеими ролями, они увидят все строки таблицы payroll .

Оптимизация RLS

RLS работает путем автоматического применения фильтров к каждому запросу DAX, и эти фильтры могут негативно повлиять на производительность запросов. Таким образом, эффективная модель RLS сводится к хорошей модели. Важно следовать рекомендациям по проектированию моделей, как описано в следующих статьях:

• Общие сведения о схеме звезд и важности Power BI
• Все статьи по рекомендациям по связям, приведенные в документации по Power BI

Как правило, часто более эффективно применять фильтры RLS в таблицах типов измерений, а не таблицы типа фактов. И опирайтесь на хорошо разработанные связи, чтобы фильтры RLS распространялись в другие таблицы моделей. Фильтры RLS распространяются только через активные связи. Поэтому не используйте функцию LOOKUPVALUE DAX, если отношения модели могут достичь того же результата.

Всякий раз, когда фильтры RLS применяются к таблицам DirectQuery и существуют связи с другими таблицами DirectQuery, обязательно оптимизируйте исходную базу данных. Он может включать проектирование соответствующих индексов или использование сохраненных вычисляемых столбцов. Дополнительные сведения см . в руководстве по модели DirectQuery в Power BI Desktop.

Измерение влияния RLS

Можно измерить влияние фильтров RLS в Power BI Desktop с помощью Анализатор производительности. Сначала определите длительность визуального запроса отчета, когда RLS не применяется. Затем используйте команду View As на вкладке ленты моделирования для принудительного применения RLS и определения и сравнения длительности запросов.

Настройка сопоставлений ролей

После публикации в Power BI необходимо сопоставить элементы с семантической моделью (ранее известной как набор данных). Только владельцы семантических моделей или администраторы рабочей области могут добавлять участников в роли. Дополнительные сведения см. в разделе "Безопасность на уровне строк" (RLS) с помощью Power BI (управление безопасностью в модели).

Участники могут быть учетными записями пользователей, группами безопасности, группами рассылки или группами с поддержкой почты. По возможности рекомендуется сопоставить группы безопасности с семантических ролей модели. Он включает управление членством в группах безопасности в идентификаторе Microsoft Entra (ранее известном как Azure Active Directory). Возможно, он делегирует задачу администраторам сети.

Проверка ролей

Проверьте каждую роль, чтобы убедиться, что она правильно фильтрует модель. Это легко сделать с помощью команды View As на вкладке ленты моделирования .

Если модель имеет динамические правила с помощью функции USERNAME DAX, обязательно проверьте ожидаемые и непредвиденные значения. При внедрении содержимого Power BI ( в частности с помощью внедрения для вашего сценария клиентов ) логика приложения может передать любое значение в качестве эффективного имени пользователя удостоверения. По возможности убедитесь, что случайные или вредоносные значения приводят к фильтрам, возвращающим строки.

Рассмотрим пример использования Power BI Embedded, где приложение передает роль задания пользователя в качестве эффективного имени пользователя: это "Manager" или "Worker". Руководители могут видеть все строки, но рабочие могут видеть только строки, в которых значение столбца Type имеет значение Internal.

Определяется следующее выражение правила:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

Проблема с этим выражением правила заключается в том, что все значения, кроме "Worker", возвращают все строки таблицы. Таким образом, случайное значение, например Wrker, непреднамеренно возвращает все строки таблицы. Поэтому для записи выражения, которое проверяет каждое ожидаемое значение, безопаснее. В следующем улучшенном выражении правила непредвиденное значение приводит к тому, что в таблице не возвращаются строки.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Проектирование частичных RLS

Иногда вычисления требуют значений, которые не ограничены фильтрами RLS. Например, отчету может потребоваться отобразить соотношение доходов, заработанных для региона продаж отчета по всему доходу, полученному пользователем.

Хотя для выражения DAX невозможно переопределить RLS ( на самом деле, он даже не может определить, что RLS применяется), можно использовать таблицу сводной модели. Таблица сводной модели запрашивается, чтобы получить доход для всех регионов, и он не ограничен фильтрами RLS.

Давайте посмотрим, как реализовать это требование проектирования. Во-первых, рассмотрим следующую модель:

Модель состоит из четырех таблиц:

• Таблица Salesperson хранит по одной строке на продавца. Он включает столбец EmailAddress , в котором хранится адрес электронной почты для каждого продавца. Эта таблица скрыта.
• В таблице Sales хранится одна строка для каждого заказа. Она включает в себя меру «Доход % всех регионов », которая предназначена для возврата соотношения доходов, полученных регионом пользователя отчета по сравнению с выручкой, полученной всеми регионами.
• Таблица Date хранит одну строку на дату и позволяет фильтровать и группировать год и месяц.
• SalesRevenueSummary — это вычисляемая таблица. Он сохраняет общий доход для каждой даты заказа. Эта таблица скрыта.

Следующее выражение определяет вычисляемую таблицу SalesRevenueSummary :

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Примечание.

Таблица агрегирования может достичь того же требования к проектированию.

К таблице Salesperson применяется следующее правило RLS:

[EmailAddress] = USERNAME()

Каждая из трех связей модели описана в следующей таблице:

Отношение	Description
	Существует связь "многие ко многим" между таблицами Salesperson и Sales . Правило RLS фильтрует столбец EmailAddress скрытой таблицы Salesperson с помощью функции USERNAME DAX. Значение столбца региона (для пользователя отчета) распространяется в таблицу Sales .
	Между таблицами Date и Sales существует связь "один ко многим".
	Существует связь "один ко многим" между таблицами Date и SalesRevenueSummary .

Следующее выражение определяет меру "Доход % все регион ".

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Примечание.

Старайтесь избежать раскрытия конфиденциальных фактов. Если в этом примере существует только два региона, то для пользователя отчета можно вычислить доход для другого региона.

Когда избежать использования RLS

Иногда рекомендуется избегать использования RLS. Если у вас есть только несколько простых правил RLS, которые применяют статические фильтры, рассмотрите возможность публикации нескольких семантических моделей. Ни одна из семантических моделей не определяет роли, так как каждая семантическая модель содержит данные для определенной аудитории пользователя отчета, которая имеет одинаковые разрешения на данные. Затем создайте одну рабочую область для каждой аудитории и назначьте разрешения доступа рабочей области или приложению.

Например, компания с двумя регионами продаж решает опубликовать семантику модели для каждого региона продаж в разных рабочих областях. Семантические модели не применяют RLS. Однако они используют параметры запроса для фильтрации исходных данных. Таким образом, одна и та же модель публикуется в каждой рабочей области— они просто имеют разные значения параметров семантической модели. Продавцы назначают доступ только к одной из рабочих областей (или опубликованных приложений).

Существует несколько преимуществ, связанных с предотвращением RLS:

• Улучшенная производительность запросов: это может привести к повышению производительности из-за меньшего количества фильтров.
• Меньшие модели: в то время как это приводит к большему числу моделей, они меньше размера. Небольшие модели могут повысить скорость реагирования на запросы и обновление данных, особенно если емкость размещения оказывает давление на ресурсы. Кроме того, проще сохранить размеры моделей ниже ограничений размера, введенных вашей емкостью. Наконец, проще сбалансировать рабочие нагрузки в разных емкостях, так как вы можете создавать рабочие области в разных емкостях или перемещать рабочие области в разные емкости.
• Дополнительные функции: можно использовать функции Power BI, которые не работают с RLS, например публикация в Интернете.

Однако существуют недостатки, связанные с предотвращением RLS:

• Несколько рабочих областей: для каждой аудитории пользователей отчета требуется одна рабочая область. Если приложения публикуются, это также означает, что для каждой аудитории отчета есть одно приложение.
• Дублирование содержимого: Отчеты и панели мониторинга должны создаваться в каждой рабочей области. Для настройки и обслуживания требуется больше усилий и времени.
• Пользователи с высоким уровнем привилегий: пользователи с высоким уровнем привилегий, принадлежащие нескольким аудиториям пользователей отчета, не могут видеть консолидированное представление данных. Им потребуется открыть несколько отчетов (из разных рабочих областей или приложений).

Устранение неполадок с RLS

Если RLS выдает непредвиденные результаты, проверка для следующих проблем:

• Неправильные связи существуют между таблицами моделей с точки зрения сопоставлений столбцов и направлений фильтрации. Помните, что фильтры RLS распространяются только через активные связи.
• Фильтр "Применить безопасность" в обоих направлениях не задан правильно. Дополнительные сведения см . в руководстве по двунаправленным отношениям.
• Таблицы не содержат данных.
• Неправильные значения загружаются в таблицы.
• Пользователь сопоставляется с несколькими ролями.
• Модель включает в себя таблицы агрегирования, а правила RLS не последовательно фильтруют агрегаты и сведения. Дополнительные сведения см. в статье Об использовании агрегатов в Power BI Desktop (RLS для агрегирования).

Если конкретный пользователь не видит никаких данных, это может быть связано с тем, что его имя участника-пользователя не хранится или введено неправильно. Это может произойти внезапно, так как учетная запись пользователя изменилась в результате изменения имени.

Совет

В целях тестирования добавьте меру, которая возвращает функцию USERNAME DAX. Вы можете назвать его примерно так: "Кто Я". Затем добавьте меру в визуальный элемент карта отчета и опубликуйте его в Power BI.

Создатели и потребители с разрешением только на чтение в семантической модели смогут просматривать данные, которые они могут просматривать (на основе сопоставления ролей RLS).

Когда пользователь просматривает отчет в рабочей области или приложении, RLS может или не применяться в зависимости от разрешений семантической модели. По этой причине важно, чтобы потребители содержимого и создатели имели разрешение только на чтение базовой семантической модели, когда необходимо применить RLS. Дополнительные сведения о правилах разрешений, определяющих применение RLS, см. в статье планирования безопасности потребителей отчета.

Связанный контент

Дополнительные сведения, связанные с этой статьей, проверка следующие ресурсы:

• Row-level security (RLS) with Power BI (Безопасность на уровне строк (RLS) в Power BI)
• Ограничение доступа к данным с помощью безопасности на уровне строк (RLS) для Power BI Desktop
• Связи модели в Power BI Desktop
• Планирование реализации Power BI: планирование безопасности потребителей
• Вопросы? Задайте их в сообществе Power BI.
• Есть предложения? Участие в разработке идей по улучшению Power BI