Планирование реализации Power BI: планирование безопасности потребителей

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

• администраторы Power BI: администраторы, ответственные за надзор за Power BI в организации.
• Центр знаний, ИТ-отдел и команда бизнес-аналитики: команды, которые также отвечают за надзор за Power BI. Им может потребоваться совместная работа с администраторами Power BI, группами информационной безопасности и другими соответствующими командами.
• Создатели и владельцы контента: разработчики бизнес-аналитики для самообслуживания, которым необходимо создавать, публиковать, защищать и управлять контентом, который используют другие пользователи.

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

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

Чтобы получить больше всего из этой статьи, полезно понять смысл терминов совместного использования и распространения в контексте Power BI.

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

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

Когда вы разговариваете с другими людьми, определите, используют ли они термин шаринг в общем смысле или буквально. Использование термина sharing можно интерпретировать двумя способами.

• Термин sharing часто используется в общем контексте, связанном с предоставлением доступа к содержимому коллегам. Существует несколько методов доставки содержимого только для чтения, которые описаны в этой статье.
• Общий доступ также является определенной функцией в Power BI. Это возможность предоставления пользователю или группе доступа к одному элементу. Ссылки на общий доступ и прямой доступ описаны в этой статье.

Стратегия для потребителей с правами только на чтение

В служба Power BI потребители могут просматривать отчет или панель мониторинга, если у них есть разрешение на оба:

• Просмотрите элемент Power BI, содержащий визуализации (например, отчет или панель мониторинга).
• Чтение базовых данных (семантическая модель или другой источник).

Вы можете предоставить доступ только для чтения потребителям с помощью различных методов. К общим методам, используемым создателями контента самообслуживания, относятся:

• Предоставление пользователям и группам доступа к приложению Power BI.
• Добавление пользователей и групп в роль средства просмотра рабочей области Power BI.
• Предоставление пользователям и группам разрешений для каждого элемента с помощью ссылки общего доступа.
• Предоставление пользователям и группам разрешений для каждого элемента с помощью прямого доступа.

Параметры роли "Средство просмотра рабочих областей Power BI" и приложения Power BI включают управление разрешениями для набора элементов. Два метода разрешений для каждого элемента включают управление разрешениями для одного отдельного элемента.

При просмотре параметров безопасности для элемента вы можете увидеть, что его разрешения бывают следующими:

• Наследуется от рабочей области или приложения.
• Применяется непосредственно к элементу.

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

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

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

Разрешения приложения Power BI

Приложение Power BI предоставляет пользователям коллекцию отчетов, панелей мониторинга и книг. Приложение обеспечивает лучший пользовательский интерфейс для потребителей, так как:

• Панель навигации приложения обеспечивает простой и интуитивно понятный пользовательский интерфейс. Это более удобный интерфейс, чем доступ к содержимому непосредственно в рабочей области.
• Содержимое можно логически упорядочить в разделы (такие как папки) в области навигации приложения.
• Потребители имеют доступ только к определенным элементам, которые явно включены в приложение для своей аудитории.
• Ссылки на дополнительные сведения, документацию или другое содержимое можно добавить в область навигации для своей аудитории.
• Существует встроенный рабочий процесс запроса доступа.

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

Вы управляете разрешениями приложений отдельно от ролей рабочей области. Разделение разрешений имеет два преимущества. Поощряет:

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

Все пользователи с доступом к рабочей области могут автоматически просматривать приложение (когда приложение Power BI опубликовано для рабочей области). Из-за этого вы можете концептуально рассматривать роли рабочей области как унаследованные каждой аудиторией приложений. Некоторые пользователи с доступом к рабочей области также могут обновлять приложение Power BI в зависимости от назначенной роли рабочей области.

Использование приложения для распространения содержимого для потребителей с доступом только для чтения является лучшим выбором, когда:

• Вы хотите, чтобы пользователи могли просматривать только определенные элементы, видимые для этой аудитории (а не все элементы в базовой рабочей области).
• Вы хотите управлять разрешениями только для чтения для приложения отдельно от рабочей области.
• Требуется более простое управление разрешениями для пользователей с доступом только для чтения, чем управление разрешениями для каждого элемента.
• Необходимо убедиться, что защита на уровне строк применяется для пользователей (если у них есть разрешение только для чтения для базовой семантической модели).
• Необходимо убедиться, что потребители не смогут просматривать новые и измененные отчеты, пока приложение не будет повторно опубликовано.

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

• Немедленные изменения семантической модели: изменения семантической модели всегда вступают в силу немедленно. Например, если вы вносите разрушающие изменения в семантическую модель в рабочей области, это может непреднамеренно вызвать нестабильность отчетов (даже если они не были повторно опубликованы в приложении). Существует два способа устранения этого риска. Во-первых, выполните все действия по разработке в Power BI Desktop (отдельно от рабочей области). Во-вторых, изолируйте продуктовое приложение, используя отдельные рабочие пространства для разработки и тестирования. (При необходимости можно добиться более высокого уровня контроля над развертыванием содержимого рабочей области, начиная с разработки и далее к тестированию и производственной среде, с помощью потоков развертывания.)
• Содержимое и разрешения публикуются вместе: при публикации приложения его разрешения публикуются одновременно с содержимым. Например, у вас могут быть изменения в отчёте в рабочей области, которые еще не завершены, полностью протестированы или утверждены. Таким образом, вы не можете повторно опубликовать приложение только для обновления разрешений. Чтобы устранить этот риск, назначьте разрешения приложений группам безопасности и используйте членства в группах безопасности (а не отдельных пользователей) при предоставлении разрешений приложения. Избегайте повторной публикации приложения только для применения изменений разрешений.

Аудитория приложений

Каждая рабочая область в службе Power BI может иметь не более одного приложения Power BI. Однако в приложении можно создать одну или несколько аудиторий. Рассмотрим следующий сценарий.

• У вас есть пять отчетов о продажах, распределенных для многих пользователей во всей глобальной организации продаж.
• Одна аудитория определяется в приложении для представителей продаж. Эта аудитория может просматривать три из пяти отчетов.
• Другая аудитория определена в приложении для команды руководителей продаж. Эта аудитория может просматривать все пять отчетов, включая два отчета, которые недоступны для представителей продаж.

Эта возможность смешивать и сопоставлять содержимое и аудитории имеет следующие преимущества.

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

На следующем снимке экрана показано приложение с двумя аудиториями: «Руководители отдела продаж» и «Торговые представители» . Панель "Управление доступом к аудитории" предоставляет доступ к группе аудитории "Руководство по продажам" для двух групп безопасности: "Руководство по продажам" Северная Америка и "Руководство по продажам" в Европе. Отчет об анализе валовой прибыли, представленный на снимке экрана для группы «Руководство по продажам», недоступен для группы «Представители по продажам».

При управлении разрешениями для приложения на странице Direct Access можно просмотреть участников каждой аудитории. Вы также можете видеть пользователей с ролью рабочей области, указанной в разделе " Все аудитории". Не удается обновить разрешения приложения на странице Direct Access . Вместо этого необходимо повторно опубликовать приложение. Однако вы можете обновить разрешения приложения на странице "Ожидание", если для приложения есть запросы на открытый доступ.

Параметры разрешения приложения

При создании (или повторной публикации) приложения для каждой аудитории есть панель Управление доступом к аудитории. В этой панели предоставлены следующие разрешения.

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

Возможность добавления разрешений повторного доступа к семантической модели или сборки при публикации приложения удобна. Однако рекомендуется управлять разрешениями приложений и разрешениями семантической модели отдельно. Вот почему.

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

Права предварительной установки приложения

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

Альтернативный подход к установке приложения заключается в том, чтобы отправить его потребителям приложений. Он приводит к предварительной установке приложения, чтобы оно автоматически отображалось на странице "Приложения" в служба Power BI. Этот подход является удобством для потребителей, так как им не нужно находить и устанавливать приложение. Однако предварительно установленные приложения могут стать раздражающими для пользователей, так как они могут стать перегружены слишком большим количеством приложений, которые не относятся к ним.

Параметры клиента push-приложений для конечных пользователей управляют тем, кто может автоматически устанавливать приложения. Мы рекомендуем использовать эту функцию, так как это удобно для пользователей. Тем не менее, мы также рекомендуем обучить создателей контента, когда его использовать, чтобы его не использовали чрезмерно.

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

Роль средства просмотра рабочей области

Как описано в статьях планирования рабочей области, основная цель рабочей области — совместная работа. Сотрудники рабочей области, такие как создатели семантической модели, создатели отчетов и тестировщики, должны быть назначены одной из трех ролей: участник, участник или администратор. Эти роли описаны в статье планирования безопасности создателя контента.

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

Предоставление потребителям доступа к содержимому рабочей области напрямую является хорошим выбором, когда:

• Формальность приложения с отдельными разрешениями не требуется.
• Зрители могут просматривать все элементы, хранящиеся в рабочей области.
• Требуется более простое управление разрешениями, чем разрешения для каждого элемента.
• Пользователи рабочей области также могут просматривать приложение (когда приложение публикуется для рабочей области).
• Предполагается, что зрители будут просматривать содержимое перед его публикацией в приложении.

Ниже приведены некоторые рекомендации по поддержке средств просмотра рабочих областей.

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

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

Разрешения для каждого элемента

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

Разрешения для каждого элемента являются хорошим выбором, когда:

• Вы хотите предоставить доступ только для чтения к одному элементу (отчету или панели мониторинга).
• Вы не хотите, чтобы потребитель просматривал все содержимое, опубликованное в рабочей области.
• Вы не хотите, чтобы потребитель просматривал все содержимое, опубликованное в аудитории приложения.

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

Совместное использование многих элементов с помощью разрешений для каждого элемента может быть утомительным и подвержено ошибкам, особенно при совместном использовании для отдельных пользователей, а не групп. Рассмотрим этот сценарий: у вас есть 40 отчетов, которые вы предоставили коллегам с помощью отдельных учетных записей пользователей. Когда один коллега передается в другой отдел, вам потребуется отозвать доступ, который будет включать разрешения на редактирование для всех 40 отчетов.

При совместном использовании отдельного элемента у вас есть несколько параметров разрешений.

• Разрешение повторного доступа: при включении пользователи могут совместно использовать элемент с другими пользователями, включая ее базовые семантические модели. Это разрешение имеет смысл предоставить, когда элемент может быть легко предоставлен любому пользователю. Он удаляет элемент управления от пользователя или команды, которая управляет элементом. Таким образом, он полагается на здравый смысл пользователей, которым предоставлено разрешение на перепубликацию. Тем не менее, ваши внутренние политики управления или безопасности могут стать более сложными для управления, если разрешено повторное распространение.
• Разрешение на сборку: при включении пользователи получают разрешение на сборку для базовой семантической модели. Разрешение на сборку позволяет пользователям создавать новое содержимое на основе семантической модели. Кроме того, они позволяют экспортировать базовые данные из отчетов и многое другое. Рекомендации по предоставлению разрешения на создание/сборку описаны в статье по планированию безопасности для создателей контента.

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

• Становится сложнее определить, какое содержимое было предоставлено пользователям, так как разрешения для каждого отчета и панели мониторинга должны быть рассмотрены по отдельности.
• Во многих случаях разрешение повторного доступа устанавливается, так как взаимодействие с пользователем включает этот параметр по умолчанию. Таким образом, существует риск того, что содержимое предоставляется более широкому набору пользователей, чем предполагается. Этот результат можно предотвратить, если снять флажок Разрешить получателям предоставлять общий доступ к этой отчетности при распространении. Минимизация излишнего разглашения информации является вопросом обучения пользователей. Создатель контента, задающий разрешения на общий доступ, должен учитывать этот выбор каждый раз.
• Все изменения отчетов и панелей мониторинга доступны другим пользователям немедленно, что может спутать пользователей, когда изменения содержимого выполняются. Эта проблема может быть устранена путем распространения содержимого в приложении или с помощью отдельных рабочих областей для разделения разработки, тестирования и рабочего содержимого. Дополнительные сведения см. в сценарии самостоятельной публикации контента.
• Когда пользователь предоставляет общий доступ к содержимому из своей личной рабочей области и покидает организацию, ИТ-специалисты обычно отключают свою учетную запись пользователя. В этом случае все получатели общего содержимого немедленно потеряют доступ к содержимому.

Существует три конкретных типа обмена: ссылки для обмена, прямой доступ и совместные отображения.

Ссылки на разрешения для каждого элемента

При совместном использовании отдельного элемента по умолчанию создается ссылка для общего доступа. Существует три типа ссылок общего доступа.

• Пользователи в вашей организации: если включено в параметрах клиента Fabric, этот тип ссылки для общего доступа является простым способом предоставления доступа только для чтения всем пользователям в организации. Однако ссылка на общий доступ не будет работать для внешних пользователей. Этот вариант лучше всего подходит, когда любой пользователь может просматривать содержимое, и ссылка может быть свободно предоставлена всей организации. Если параметр клиента Разрешить ссылки для предоставления доступа всем пользователям в вашей организации не отключен, то этот тип общего доступа используется по умолчанию.
• Пользователи с существующим доступом: этот параметр не создает новую ссылку для общего доступа. Скорее, он позволяет получить URL-адрес, чтобы отправить его пользователю, у которого уже есть доступ.
• Конкретные пользователи: этот параметр создает ссылку на общий доступ для определенных пользователей или групп. Рекомендуется использовать этот вариант чаще всего, так как он предоставляет конкретный доступ. Если вы обычно работаете с внешними пользователями, вы можете использовать эту ссылку для гостевых пользователей, которые уже существуют в идентификаторе Microsoft Entra. Дополнительные сведения о запланированном процессе приглашения для создания гостевых пользователей см. в статье о планировании безопасности на уровне клиента.

Ссылка на общий доступ добавляет разрешение на чтение элемента. Разрешение reshare выбрано по умолчанию. Кроме того, можно добавить разрешение на сборку в базовую семантику в то же время, когда создается ссылка общего доступа.

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

• Ссылка на общий доступ: 20 отдельных пользователей получают доступ с помощью ссылки общего доступа. При одном изменении ссылки это влияет на всех 20 пользователей.
• Прямой доступ: 20 человек получают прямой доступ к элементу. Чтобы внести изменения, необходимо изменить все 20 разрешений пользователей.

Разрешения прямого доступа для каждого элемента

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

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

Общие представления

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

Общие представления — это временная концепция. Срок действия автоматически истекает через 180 дней. По этой причине общие представления лучше всего подходят для неформальных и временных сценариев общего доступа. Убедитесь, что пользователи знают об этом ограничении.

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

Другие методы запросов потребителей

Наиболее распространенными способами взаимодействия потребителей с Power BI являются приложения, рабочие области и разрешения для каждого элемента (ранее описанные в этой статье).

Существуют другие методы, которые потребители могут использовать для запроса данных Power BI. Для каждой из следующих техник запроса требуется разрешение на создание семантической модели или хранилища данных.

• Анализ в Excel. Потребители, которые предпочитают использовать Excel, могут запрашивать семантику Power BI с помощью анализа в Excel. Эта возможность является отличной альтернативой экспорту данных в Excel, так как данные не дублируются. При динамическом подключении к семантической модели пользователи могут создавать сводные таблицы, диаграммы и срезы. Затем они могут опубликовать книгу в рабочее пространство в службу Power BI, что позволяет потребителям открывать ее и взаимодействовать с ней.
• Конечная точка XMLA: потребители могут запрашивать семантику модели, подключаясь к конечной точке XMLA. Приложение, совместимое с XMLA, может подключаться, запрашивать и использовать семантические модели, хранящиеся в рабочей области Premium. Эта возможность полезна, если потребители хотят использовать семантику Power BI в качестве источника данных для средства визуализации данных за пределами экосистемы Майкрософт.
• Редактор Datamart: пользователи могут выполнять запросы к Power BI Datamart с помощью редактора Datamart. Это веб-редактор визуальных запросов для создания запросов без кода. Существует также веб-редактор SQL, когда потребители предпочитают писать запросы SQL. Оба редактора запрашивают управляемую базу данных SQL Azure, которая лежит в основе хранилища данных Power BI, в отличие от встроенной семантической модели.
• Конечная точка SQL: потребители могут запрашивать datamart Power BI с помощью конечной точки SQL. Они могут использовать такие средства, как Azure Data Studio или SQL Server Management Studio (SSMS) для выполнения запросов SQL. Конечная точка SQL направляет запросы к управляемой базе данных SQL Azure, которая лежит в основе хранилища данных Power BI (а не встроенной семантической модели).

Дополнительные сведения о разрешении сборки см. в статье о планировании безопасности создателя содержимого.

Контрольный список — При планировании того, какие методы запроса будут использовать потребители, ключевые решения и действия включают:

Процесс запроса доступа для пользователей

При совместном использовании содержимого один пользователь перенаправит ссылку (URL-адрес) другому пользователю. Когда получатель пытается просмотреть содержимое и обнаруживает, что у него нет доступа, он может выбрать кнопку "Запрос доступа ". Это действие инициирует рабочий процесс доступа к запросу . Затем пользователю будет предложено предоставить сообщение, чтобы объяснить, почему они хотят получить доступ.

Рабочий процесс доступа к запросу существует для:

• Доступ к приложению Power BI.
• Доступ к элементу, например к отчету или панели мониторинга.
• Доступ к семантической модели. Дополнительные сведения о рабочем процессе доступа к запросу при обнаружении семантической модели см. в статье о планировании безопасности создателя содержимого.

Запросы на доступ к приложению

Существует два способа узнать о ожидающих запросах доступа, отправленных для приложения.

• Электронная почта: контакты для приложения получают уведомление по электронной почте. По умолчанию этот контакт является издателем приложения. Чтобы обеспечить более высокую поддержку критически важных приложений, рекомендуется настроить контакт для группы, которая может быстро реагировать на запросы доступа.
• Меню управления разрешениями: администраторы рабочей области и члены могут просматривать, утверждать или отклонять запросы на доступ. Страница "Управление разрешениями" доступна на странице "Приложения" и может быть открыта для каждого приложения. Эта возможность также доступна участникам рабочей области, если включена настройка Разрешить участникам обновлять приложение для этой рабочей области.

Ожидающие запросы доступа для приложения отображают сообщение, предоставленное пользователем. Каждый ожидающий запрос может быть утвержден или отклонен. При выборе утверждения запроса необходимо выбрать аудиторию приложения.

На следующем снимке экрана показан запрос на доступ от пользователя, который находится на рассмотрении. Чтобы утвердить его, необходимо выбрать одну из двух аудиторий приложений: "Представитель продаж" или "Руководство по продажам".

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

Запросы доступа к рабочей области

Доступ к рабочей области предоставляется пользователям, которые принадлежат роли администратора или роли участника.

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

Запросы на доступ к элементам

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

• Электронная почта: контакты для элемента получают уведомление по электронной почте. Чтобы обеспечить более высокую поддержку критически важных отчетов, рекомендуется настроить контакт для группы, которая может быстро реагировать на запросы на доступ.
• Меню управления разрешениями: администраторы рабочей области и члены могут получить доступ к странице "Управление разрешениями " для каждого элемента. Они могут просматривать, утверждать или отклонять запросы на доступ, находящиеся в ожидании.

Управление запросами доступа с помощью групп

Когда пользователь отправляет форму доступа к запросу для элемента Power BI (например, отчета или семантической модели) или приложения Power BI, запрос отправляется для отдельного пользователя. Однако многие крупные организации должны использовать группы для соблюдения своих внутренних политик безопасности.

Рекомендуется использовать группы, а не отдельных лиц для защиты содержимого при необходимости. Дополнительные сведения о планировании групп см. в статье о планировании безопасности на уровне клиента.

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

1. Отклоните ожидающий запрос в Power BI (так как он связан с отдельным пользователем).
2. Добавьте запрашиватель в правильную группу в соответствии с текущим процессом.
3. Уведомите запрашивающего, что у них теперь есть доступ.

Контрольный список. При планировании рабочего процесса доступа к запросу ключевые решения и действия включают:

Принудительное обеспечение безопасности данных на основе удостоверения потребителя

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

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

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

Безопасность данных можно выполнять несколькими способами.

• Семантическая модель Power BI: как создатель данных Power BI можно применить безопасность на уровне строк (RLS) и безопасность на уровне объектов (OLS). RLS включает определение ролей и правил, которые фильтруют строки модели данных, а OLS ограничивает доступ к определенным таблицам или столбцам. Эти определенные правила RLS и OLS не применяются к ссылкам, хранящимся вне семантической модели, например срезов и выбора фильтров. Методы RLS и OLS описаны далее в этом разделе.
• Службы Analysis Services: семантическая модель с динамическим подключением может подключаться к удаленной модели данных, размещенной в службах Azure Analysis Services (AAS) или SQL Server Analysis Services (SSAS). Удаленная модель может применять RLS или OLS в зависимости от идентичности потребителя.
• Источник данных: некоторые источники данных, такие как база данных SQL Azure, могут применять RLS. В этом случае модель Power BI может воспользоваться преимуществами существующей безопасности, а не переопределять ее. Такой подход может быть значительным преимуществом, если RLS, определенный в источнике, является сложным. Вы можете разрабатывать и публиковать модель DirectQuery и задавать учетные данные источника данных для семантической модели в службе Power BI, чтобы включить единый вход. Когда потребитель отчета открывает отчет, Power BI передает их идентификацию источнику данных. Затем источник данных применяет RLS на основе идентификации пользователя отчета. Дополнительные сведения о RLS для базы данных Azure SQL см. в этой статье.

Безопасность на уровне строк

Безопасность на уровне строк (RLS) позволяет моделиировщику данных ограничить доступ к подмножествам данных. Обычно используется для обеспечения того, чтобы некоторые потребители отчетов не могли видеть определенные данные, такие как результаты продаж других регионов продаж.

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

Существует два шага по настройке RLS: правила и сопоставления ролей.

Правила RLS

Для семантических моделей модель данных может настроить RLS в Power BI Desktop, создав одну или несколько ролей. Роль имеет уникальное имя в модели и обычно включает одно или несколько правил. Правила реализуют применение фильтров к таблицам моделей с помощью выражений анализа данных (DAX). По умолчанию модель не имеет ролей.

Выражения правил вычисляются в контексте строки. Контекст строки означает, что выражение вычисляется для каждой строки с помощью значений столбцов этой строки. Когда выражение возвращает TRUE, пользователь может увидеть строку. Вы можете задать статические или динамические правила.

• Статические правила: используйте выражения DAX, ссылающиеся на константы, например [Region] = "Midwest".
• Динамические правила: используйте определенные функции DAX, возвращающие значения среды (в отличие от констант). Значения среды возвращаются из трех конкретных функций DAX: USERNAME, USERPRINCIPALNAME и CUSTOMDATA. Определение динамических правил — это простой и эффективный способ, если в таблице модели хранятся значения имени пользователя. Они позволяют вам обеспечить реализацию RLS-дизайна на основе данных.

Сопоставления ролей RLS

После публикации модели в служба Power BI необходимо настроить сопоставления ролей перед доступом пользователей к соответствующим отчетам. Сопоставление ролей включает назначение ролей объектам безопасности Microsoft Entra. Объектами безопасности могут быть учетные записи пользователей или группы безопасности.

По возможности рекомендуется сопоставить роли с группами безопасности. Таким образом, будет меньше сопоставлений, а управление членством в группах может обрабатываться владельцем группы.

Мы рекомендуем сделать сведения об учетной записи безопасности из Microsoft Entra доступными создателям содержимого. Одним из вариантов является создание потока данных, который остаётся в синхронизации с Microsoft Entra ID. Таким образом создатели контента могут интегрировать данные потока данных для создания управляемой данными семантической модели.

Взаимодействие с пользователем RLS

Некоторые организации решили использовать RLS в качестве дополнительного уровня безопасности в дополнение к стандартным разрешениям Power BI. Рассмотрим следующий сценарий: вы предоставляете ссылку на отчет всей организации. Любой пользователь, который просматривает отчет, должен быть назначен на роль RLS, чтобы видеть данные в отчете. Если они не сопоставлены с ролью RLS, они не увидят никаких данных.

Наличие RLS изменяет интерфейс по умолчанию для потребителей.

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

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

Ниже приведены правила разрешений, определяющие, применяется ли RLS.

• Пользователь имеет разрешение на чтение семантической модели: RLS применяется для пользователя.
• У пользователя есть разрешения на чтение и сборку для семантической модели: RLS применяется для пользователя.
• Пользователь имеет разрешение на запись в семантической модели: RLS не применяется для пользователя, то есть они могут видеть все данные в семантической модели. Разрешение на запись предоставляет возможность редактирования семантической модели. Его можно предоставить одним из двух способов:
  • С ролями вкладчика, члена рабочей области или администратора (для рабочей области, в которой хранится семантическая модель).
  • Разрешение на запись семантической модели для каждого элемента.

Дополнительные сведения о RLS см. в разделе "Ограничение доступа к данным модели Power BI".

RLS для datamarts

Магазины данных Power BI также могут применять RLS. Однако реализация отличается.

Основное различие заключается в том, что RLS для датамартов настраивается в службе Power BI, а не в Power BI Desktop.

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

Более подробную информацию см. в разделе RLS для datamarts.

Безопасность на уровне объекта

Безопасность на уровне объектов (OLS) позволяет моделиировщику данных ограничить доступ к определенным таблицам и столбцам, а также их метаданным. Обычно вы используете OLS, чтобы гарантировать, что конфиденциальные столбцы, такие как зарплата сотрудников, невидимы определённым пользователям. Хотя невозможно ограничить доступ к мерам, любая мера, ссылающаяся на ограниченный столбец, будет ограничена.

Рассмотрим пример таблицы сотрудников. Он содержит столбцы, которые хранят имя сотрудника и номер телефона, а также зарплату. Вы можете использовать OLS, чтобы убедиться, что только некоторые пользователи, такие как старшие сотрудники отдела кадров, могут видеть значения заработной платы. Для тех пользователей, которые не могут видеть значения заработной платы, это так, как если бы этот столбец не существовал.

Обратите внимание, так как если визуальный элемент отчета Power BI включает зарплату, пользователи, у которых нет доступа к такому полю, получат сообщение об ошибке. Сообщение сообщит им о том, что объект не существует. Для этих пользователей отчет выглядит сломанным.

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

Дополнительные сведения об OLS см. в разделе "Ограничение доступа к объектам модели Power BI".

Контрольный список . При планировании RLS и OLS ключевые решения и действия включают:

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

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