Планирование реализации Power BI: планирование безопасности создателя содержимого

Мақала
11/10/2023

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется интерфейсу Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

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

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

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

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

Совет

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

Стратегия создателей содержимого

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

Совет

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

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

Создатели данных

Создатель данных — это любой пользователь Power BI, который создает семантические модели, потоки данных или диаграммы данных.

Ниже приведены некоторые распространенные сценарии создания данных.

Создайте семантику модели: создайте и проверьте новую модель данных в Power BI Desktop. Затем она публикуется в служба Power BI, чтобы ее можно было использовать в качестве общей семантической модели для многих отчетов. Дополнительные сведения о повторном использовании общих семантических моделей см. в сценарии использования управляемой бизнес-аналитики самообслуживания.
Расширение и настройка семантической модели. Создание динамического подключения к существующей общей семантической модели в Power BI Desktop. Преобразуйте динамическое подключение в локальную модель, которая позволяет расширить структуру модели с новыми таблицами или столбцами. Дополнительные сведения о расширении и настройке общих семантических моделей см. в сценарии использования управляемой управляемой аналитики самообслуживания.
Создайте новый поток данных: в служба Power BI создайте новый поток данных, чтобы его можно было использовать в качестве источника для многих семантических моделей. Дополнительные сведения о повторном использовании действий по подготовке данных см. в сценарии самостоятельной подготовки данных.
Создайте объект datamart. В служба Power BI создайте объект datamart.

Создатели данных часто находятся в корпоративных командах бизнес-аналитики и в Центре превосходства (COE). Они также играют ключевую роль в децентрализованных бизнес-подразделениях и отделах, которые поддерживают собственные данные и управляют ими.

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

Создатели отчетов

Создатели отчетов создают отчеты и панели мониторинга для визуализации данных, полученных из существующих семантических моделей.

Ниже приведены некоторые распространенные сценарии создания отчетов.

Создайте новый отчет, включая модель данных: создайте и протестируйте новый отчет и модель данных в Power BI Desktop. Файл Power BI Desktop, содержащий одну или несколько страниц отчета и содержащий модель данных, публикуется в служба Power BI. Создатели нового содержимого обычно используют этот метод, прежде чем они знают об использовании общих семантических моделей. Это также подходит для узких вариантов использования, которые не нуждаются в повторном использовании данных.
Создайте отчет о динамическом подключении: создайте новый отчет Power BI, который подключается к общей семантической модели в служба Power BI. Дополнительные сведения о повторном использовании общих семантических моделей см. в сценарии использования управляемой бизнес-аналитики самообслуживания.
Создайте подключенную книгу Excel: создайте отчет Excel, который подключается к общей семантической модели в служба Power BI. Подключение интерфейсы Excel, а не скачивание данных, настоятельно рекомендуется.
Создайте отчет DirectQuery: создайте новый отчет Power BI, который подключается к поддерживаемму источнику данных в режиме DirectQuery. Одна из ситуаций, когда этот метод полезен, заключается в том, что вы хотите воспользоваться преимуществами безопасности пользователей, реализованных исходной системой.

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

Совет

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

Разрешения для создателей

В этом разделе описываются наиболее распространенные разрешения для создателей данных и создателей отчетов.

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

Создание нового содержимого

Для создания нового содержимого обычно требуются следующие разрешения.

Разрешение	Создатель отчета	Создатель семантической модели	Создатель потока данных	Создатель Datamart
Доступ к базовому источнику данных
Разрешения на чтение и сборку семантической модели
Разрешение на чтение потока данных (при использовании потока данных в качестве источника с помощью роли средства просмотра рабочей области)
Доступ к исходному файлу Power BI Desktop
Разрешение на использование пользовательских визуальных элементов

Публикация разрешений на содержимое

Для публикации содержимого обычно требуются следующие разрешения.

Разрешение	Создатель отчета	Создатель семантической модели	Создатель потока данных	Создатель Datamart
Роль рабочей области: участник, член или Администратор
Разрешение на запись семантической модели (если пользователь не принадлежит роли рабочей области)
Роль конвейера развертывания для публикации элементов (необязательно)

Обновление данных

Для обновления данных обычно требуются следующие разрешения.

Разрешение	Создатель отчета	Создатель семантической модели	Создатель потока данных	Создатель Datamart
Владелец, назначенный (который настроил параметры или взял на себя элемент)
Доступ к базовому источнику данных (если шлюз не используется)
Доступ к источнику данных в шлюзе (если источник находится локально или в виртуальной сети)

Оставшаяся часть этой статьи описывает рекомендации по разрешениям создателя контента.

Совет

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

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

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

Обнаружение содержимого для создателей

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

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

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

Примечание.

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

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

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

Рассмотрим следующие три примера.

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

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

Сообщение о доступе к запросу считывается: для стандартных отчетов о продажах MTD/QTD/YTD эта семантическая модель является достоверным и сертифицированным источником. Запросите доступ к семантической модели, завершив форму, расположенную по адресу https://COE.contoso.com/RequestAccess. Вам будет предложено краткое бизнес-обоснование, и менеджер Центра превосходства будет требоваться для утверждения запроса. Доступ будет проверяться каждые шесть месяцев.

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

Примечание.

Язык и региональные параметры данных и ваша позиция по демократизации данных должны сильно влиять на включение обнаружения данных. Дополнительные сведения об обнаружении данных см. в настраиваемом сценарии самостоятельного использования бизнес-аналитики .

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

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

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

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

Запрос рабочего процесса доступа для создателей

Пользователь может запросить доступ к содержимому двумя способами.

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

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

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

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

На следующем снимках экрана показан пример настройки пользовательских инструкций, которые пользователь видит при запросе разрешения на сборку. Пользовательские инструкции: для стандартных отчетов о продажах MTD/QTD/YTD эта семантическая модель является достоверным и сертифицированным источником. Запросите доступ к семантической модели, завершив форму, расположенную по адресу https://COE.contoso.com/RequestAccess. Вам будет предложено краткое бизнес-обоснование, и менеджер Центра превосходства будет требоваться для утверждения запроса. Доступ будет проверяться каждые шесть месяцев.

Снимок экрана: параметр доступа запроса для семантической модели в служба Power BI.

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

Мы рекомендуем создать полезные сведения для:

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

Совет

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

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

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

Создание и публикация содержимого

В этом разделе содержатся аспекты безопасности, которые применяются к создателям содержимого.

Примечание.

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

Роли рабочей области

Вы предоставляете доступ к рабочей области путем добавления пользователей или групп (включая группы безопасности, группы Microsoft 365 и списки рассылки) в роли рабочей области. Назначение пользователям ролей рабочей области позволяет указать, что они могут делать с рабочей областью и его содержимым.

Примечание.

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

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

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

Существует четыре роли рабочей области Power BI: Администратор, член, участник и средство просмотра. Первые три роли относятся к создателям контента, которые создают и публикуют содержимое. Роль просмотра относится к потребителям только для чтения.

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

Совет

См. документацию по ролям рабочей области для достоверной ссылки на каждую из четырех ролей.

Администратор рабочей области

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

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

Совет

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

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

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

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

Член рабочей области

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

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

Участники рабочей области должны быть ограничены пользователями, которым необходимо управлять созданием содержимого рабочей области и публиковать это приложение. В некоторых случаях администраторы рабочей области выполняют эту задачу, поэтому вам может не потребоваться назначить пользователей или группы роли участника. Если администраторы рабочей области не связаны напрямую с содержимым рабочей области (например, так как ИТ управляет процессом создания рабочей области), члены рабочей области могут быть истинными владельцами, ответственными за содержимое рабочей области.

Участник рабочей области

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

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

Большинство создателей контента в организации — это участник рабочей области.

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

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

Роль просмотра относится к потребителям только для чтения для небольших команд и неофициальных сценариев. Он полностью описан в статье планирования безопасности потребителей отчета.

Вопросы владения рабочей областью

Рассмотрим пример, в котором выполняются следующие действия для настройки новой рабочей области.

Определенные чемпионы Power BI и вспомогательные члены Центра превосходства (COE) получили разрешение на создание новых рабочих областей в параметрах клиента. Они были обучены в стратегиях организации содержимого и стандартах именования.
Вы (создатель контента) отправляете запрос на создание рабочей области для нового проекта, который вы будете управлять. Рабочая область будет включать отчеты, отслеживающие ход выполнения проекта.
Участник Power BI для вашей бизнес-единицы получает запрос. Они определяют, что новая рабочая область оправдана. Затем они создают рабочую область и назначают группе безопасности чемпионов Power BI (для своей бизнес-единицы) роли Администратор рабочей области.
Чемпион Power BI назначает вас (создателю содержимого) роли участника рабочей области.
Вы назначаете доверенному коллеге роль участника рабочей области, чтобы убедиться, что у вас есть резервная копия.
Вы назначаете другим коллегам роль участника рабочей области, так как они будут отвечать за создание содержимого рабочей области, включая семантические модели и отчеты.
Вы назначаете руководителю роль средства просмотра рабочей области, так как они запрашивали доступ для мониторинга хода выполнения проекта. Перед публикацией приложения руководитель хотел бы просмотреть содержимое в рабочей области.
Вы несете ответственность за управление другими свойствами рабочей области, такими как описание и контакты. Вы также несете ответственность за управление доступом к рабочей области на постоянной основе.

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

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

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

Варианты ролей рабочей области

Существует два варианта для четырех ролей рабочей области (описанных ранее).

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

Внимание

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

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

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

Разрешения создателя приложений

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

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

Совет

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

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

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

Разрешения источника данных

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

Доступ к источнику данных

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

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

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

Совет

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

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

Совет

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

Учетные данные (учетная запись и пароль) можно применять одним из двух способов.

Power BI Desktop: учетные данные шифруются и хранятся локально на пользовательском компьютере.
служба Power BI: Учетные данные шифруются и безопасно хранятся для следующих компонентов:
- Семантическая модель (если шлюз данных не используется для доступа к источнику данных).
- Источник данных шлюза (если используется стандартный шлюз или служба шлюза виртуальной сети для доступа к источнику данных).

Совет

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

Учетные данные шифруются и хранятся отдельно от модели данных в Power BI Desktop и служба Power BI. Это разделение данных имеет следующие преимущества безопасности.

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

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

Уровни конфиденциальности

Уровни конфиденциальности данных указывают уровни изоляции, определяющие степень изоляции одного источника данных от других источников данных. При необходимости они гарантируют, что Power Query передает только совместимые данные между источниками. Когда Power Query может передавать данные между источниками данных, это может привести к более эффективным запросам, которые сокращают объем данных, отправленных в Power BI. Если данные не могут передаваться между источниками данных, это может привести к снижению производительности.

Существует три уровня конфиденциальности.

Частный: включает конфиденциальные или конфиденциальные данные, которые должны быть изолированы от всех других источников данных. Этот уровень является самым строгим. Не удается предоставить общий доступ к данным частного источника данных другим источникам данных. Например, для базы данных кадров, содержащей значения заработной платы сотрудника, следует задать уровень конфиденциальности частной конфиденциальности.
Организация: изолирована от общедоступных источников данных, но отображается для других источников данных организации. Этот уровень является наиболее распространенным. Данные источника данных организации можно совместно использовать с частными источниками данных или другими источниками данных организации. Большинство внутренних операционных баз данных можно задать с уровнем конфиденциальности организации.
Общедоступные: нечувствительные данные, которые можно сделать видимыми для любого источника данных. Этот уровень является наименее строгим. Общедоступные данные источника данных можно совместно использовать с любым другим источником данных. Например, отчет о переписи, полученный на веб-сайте правительства, можно задать на уровне общественной конфиденциальности.

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

Рассмотрим сценарий, в котором создатель семантической модели имеет два источника данных: книгу Excel и таблицу в База данных SQL Azure. Они хотят отфильтровать данные в таблице База данных SQL Azure с помощью значения, полученного из книги Excel. Наиболее эффективным способом создания инструкции SQL для База данных SQL Azure является применение предложения WHERE для выполнения необходимой фильтрации. Однако эта инструкция SQL будет содержать предикат предложения WHERE со значением, источником которого является книга Excel. Если книга Excel содержит конфиденциальные данные, это может представлять собой нарушение безопасности, так как администратор базы данных может просматривать инструкцию SQL с помощью средства трассировки. Хотя и менее эффективным, альтернативой является подсистема mashup Power Query, чтобы скачать весь результирующий набор таблицы базы данных и выполнить фильтрацию в служба Power BI. Этот подход будет менее эффективным и медленным, но безопасным.

Уровни конфиденциальности можно задать для каждого источника данных:

По моделирователям данных в Power BI Desktop.
Владельцы семантической модели в служба Power BI (для облачных источников данных, которые не требуют шлюза).
Создатели и владельцы источников данных шлюза в служба Power BI (для источников данных шлюза).

Внимание

Уровни конфиденциальности, заданные в Power BI Desktop, не передаются в служба Power BI.

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

Дополнительные сведения см. в статье Уровни конфиденциальности Power BI Desktop.

Запросы к собственной базе данных

Чтобы создать эффективные запросы Power Query, можно использовать собственный запрос для доступа к данным. Собственный запрос — это инструкция, написанная на языке, поддерживаемом источником данных. Собственные запросы поддерживаются только определенными источниками данных, которые обычно являются реляционными базами данных, такими как База данных SQL Azure.

Собственные запросы могут представлять угрозу безопасности, так как они могут запускать вредоносные инструкции SQL. Вредоносный оператор может выполнять изменения данных или удалять записи базы данных (если у пользователя есть необходимые разрешения в источнике данных). По этой причине по умолчанию собственные запросы требуют утверждения пользователей для запуска в Power BI Desktop.

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

Настраиваемые соединители

Разработчики могут использовать пакет SDK Power Query для создания пользовательских соединителей. Пользовательские соединители позволяют получать доступ к частным источникам данных или реализовывать определенную проверку подлинности с помощью пользовательских расширений данных. Некоторые пользовательские соединители сертифицированы и распределены корпорацией Майкрософт в качестве сертифицированных соединителей. Сертифицированные соединители были проверены и проверены, чтобы обеспечить соответствие определенным требованиям к коду, протестированным и утвержденным корпорацией Майкрософт.

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

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

Примечание.

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

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

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

Разрешения создателя семантической модели

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

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

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

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

Совет

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

Разрешения семантической модели

Вы можете назначить следующие разрешения семантической модели.

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

Администратор рабочей области или член могут изменять разрешения для семантической модели.

Разрешение на чтение семантической модели

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

Разрешение на сборку семантической модели

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

Создайте отчеты Power BI на основе семантической модели.
Подключение семантическую модель с помощью Анализ в Excel.
Запросите семантику модели с помощью конечной точки XMLA.
Экспорт визуальных данных отчета Power BI (вместо суммированных данных, полученных визуальным элементом).
Создайте подключение DirectQuery к семантической модели Power BI. В этом случае новая семантическая модель подключается к одной или нескольким существующим семантические модели Power BI (называемые цепочками). Чтобы запросить семантические модели, создатель семантической модели потребует разрешения на сборку для всех вышестоящий семантических моделей. Дополнительные сведения см. в разделе "Семантические модели в цепочке" далее в этой статье.

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

Предоставление сборки напрямую:
- Задание разрешений семантической модели на странице параметров семантической модели в служба Power BI.
- Настройка разрешений семантической модели с помощью REST API Power BI.
Предоставление косвенной сборки путем:
- Общий доступ к отчету или панели мониторинга и настройка параметра предоставления разрешения на сборку семантической модели.
- Публикация приложения Power BI и настройка расширенного параметра (для аудитории) для предоставления разрешения на сборку связанных семантических моделей.
- Назначение пользователям ролей рабочей области Администратор, участника или участника.

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

Совет

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

Разрешение на запись семантической модели

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

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

Совет

Инструкции по организации рабочих областей см. в статьях по планированию рабочих областей.

Разрешение повторной общей папки семантической модели

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

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

Безопасность данных семантической модели

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

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

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

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

Сведения о RLS и OLS, предназначенных для других создателей отчетов, см. в разделе "Безопасность данных" в разделе разрешений создателя отчета далее в этой статье.

Семантические модели семантики в цепочке

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

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

Примечание.

Создатель семантической модели позволяет ограничить цепочку семантической модели. Для этого включите подключение DirectQuery к этому параметру семантической модели в Power BI Desktop. Дополнительные сведения см. в разделе "Управление подключениями DirectQuery к опубликованной семантической модели".

Запросы API семантической модели

В некоторых ситуациях может потребоваться выполнить запрос DAX с помощью REST API Power BI. Например, может потребоваться выполнить проверку качества данных. Дополнительные сведения см. в разделе "Наборы данных— выполнение запросов".

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

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

Определите стратегию разрешений создателя семантической модели: определите, какие настройки и требования существуют для управления безопасностью для создателей семантической модели. Рассмотрим область темы и уровень конфиденциальности данных. Также рассмотрим, кто может взять на себя ответственность за управление данными и разрешениями в централизованных и децентрализованных бизнес-подразделениях.
Ознакомьтесь с тем, как роли рабочей области обрабатываются для создателей семантической модели: определите влияние на процесс разработки рабочей области. Создайте отдельные рабочие области данных для каждой области темы, чтобы упростить управление ролями рабочей области и семантической безопасностью модели для каждой области темы.
Предоставьте рекомендации для создателей семантической модели по управлению разрешениями: включите документацию для создателей семантической модели о том, как управлять разрешениями семантической модели. Опубликуйте эти сведения на централизованный портал и учебные материалы.
Решите, кто может использовать подключения DirectQuery для семантических моделей Power BI. Определите, должны ли быть какие-либо ограничения, для которых создатели семантической модели Power BI (с существующим разрешением на сборку для семантической модели) могут создать подключение к семантической модели Power BI. Задайте параметр клиента "Разрешить подключения DirectQuery" к семантической модели Power BI, чтобы выровнять это решение. Если вы решите ограничить эту возможность, попробуйте использовать группу, например авторов утвержденных семантических моделей Power BI.
Решите, кто может запрашивать семантические модели Power BI с помощью REST API: решите, следует ли ограничить создателей содержимого Power BI запросы к семантической модели Power BI с помощью REST API Power BI. Задайте параметр клиента REST API выполнения запросов набора данных, чтобы выровнять это решение. Если вы решите ограничить эту возможность, рассмотрите возможность использования группы, например утвержденных создателей отчетов Power BI.
Определите стратегию использования RLS или OLS для создателей семантической модели. Рассмотрим варианты использования и цели, которые вы планируете использовать RLS или OLS. Фактор в стратегии проектирования рабочей области и наличие разрешений на чтение и изменение, если требуется применить RLS или OLS для создателей семантической модели.

Разрешения создателя отчетов

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

По возможности создатели отчетов должны использовать существующую общую семантику модели (через динамическое подключение или DirectQuery). Таким образом процесс создания отчета отделен от процесса создания семантической модели. Этот тип разделения обеспечивает множество преимуществ для сценариев безопасности и разработки команд.

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

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

Совет

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

Разрешения на чтение и сборку для базовой семантической модели

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

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

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

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

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

Рассмотрим следующий сценарий.

Централизованные общие семантические модели с помощью RLS: команда корпоративной бизнес-аналитики опубликовала семантические модели продаж в рабочей области "Данные продаж". Эти семантические модели применяют RLS для отображения данных о продажах для назначенного региона продаж потребителя отчета.
Децентрализованные создатели отчетов самообслуживания: подразделение по продажам и маркетингу имеет множество способных аналитиков, которые создают собственные отчеты. Они публикуют свои отчеты в рабочей области Аналитики продаж.
Разрешения на чтение и сборку для семантических моделей. По возможности аналитики используют семантические модели из рабочей области "Данные продаж", чтобы избежать ненужных дублирования данных. Так как аналитики имеют разрешения только на чтение и сборку для этих семантических моделей (без разрешений на запись или редактирование), RLS применяется для создателей отчетов (а также потребителей отчетов).
Изменение разрешений для рабочей области отчетов: аналитики имеют больше прав в рабочей области Sales Analytics . Роли рабочей области администратора, члена или участник позволяют им публиковать отчеты и управлять ими.

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

Подключение для внешних семантических моделей

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

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

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

Пользовательские разрешения визуальных элементов

Помимо основных визуальных элементов создатели отчетов Power BI могут использовать пользовательские визуальные элементы. В Power BI Desktop пользовательские визуальные элементы можно скачать из Microsoft AppSource. Кроме того, их можно разработать в собственной среде с помощью пакет SDK для Power BI и установить, открыв визуальный файл (Pbviz).

Некоторые визуальные элементы, доступные для скачивания из AppSource, сертифицированы. Сертифицированные визуальные элементы соответствуют определенным требованиям к коду, которые команда Power BI проверила и одобрила. Тесты проверка, к которым визуальные элементы не обращаются к внешним службам или ресурсам.

Разрешить визуальные элементы, созданные параметром клиента пакет SDK для Power BI, позволяют администраторам Power BI контролировать, какие группы пользователей могут использовать пользовательские визуальные элементы.

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

Примечание.

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

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

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

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

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

Определите стратегию разрешений создателя отчетов: определите, какие настройки и требования существуют для управления безопасностью для создателей отчетов. Рассмотрим область темы и уровень конфиденциальности данных. Кроме того, рассмотрим, кто может взять на себя ответственность за создание отчетов и управление ими в централизованных и децентрализованных бизнес-подразделениях.
Ознакомьтесь с тем, как роли рабочей области обрабатываются для создателей отчетов: определите, что влияет на процесс разработки рабочей области. Создание отдельных рабочих областей данных и рабочих областей отчетов для каждой области темы, поэтому роли рабочей области (и безопасность базовой семантической модели) упрощаются для области темы.
Предоставьте рекомендации создателям отчетов об управлении разрешениями: включите документацию для создателей отчетов о том, как управлять разрешениями для потребителей отчетов. Опубликуйте эти сведения на централизованный портал и учебные материалы.
Решите, кто может использовать общие семантические модели. Определите, должны ли быть какие-либо ограничения, для которых создатели отчетов Power BI (у которых уже есть разрешения на чтение и сборку для семантической модели) могут использовать семантические модели в рабочих областях. Задайте для параметра клиента "Использовать семантические модели" для рабочих областей, чтобы выровнять это решение. Если вы решите ограничить эту возможность, рассмотрите возможность использования группы, например утвержденных создателей отчетов Power BI.
Решите, кто может использовать динамические подключения: определите, должны ли быть какие-либо ограничения, для которых создатели отчетов Power BI (у которых уже есть разрешение на чтение и сборку для семантической модели) могут использовать динамические подключения. Задайте параметр клиента "Разрешить динамические подключения", чтобы выровнять это решение. Если вы решите ограничить эту возможность, рассмотрите возможность использования группы, например утвержденных создателей отчетов Power BI.
Определите стратегию использования RLS для создателей отчетов: рассмотрите варианты использования и цели, которые вы планируете использовать безопасность на уровне строк. Фактор в стратегии проектирования рабочей области, чтобы обеспечить применение RLS для создателей отчетов.
Определите стратегию использования пользовательских визуальных элементов: рассмотрим стратегию, для которой создатели отчетов могут использовать пользовательские визуальные элементы. Задайте визуальные элементы allow, созданные параметром клиента пакет SDK для Power BI, чтобы выровнять это решение. При необходимости создайте процесс использования визуальных элементов организации.

Разрешения создателя потока данных

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

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

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

Помимо ролей рабочей области, необходимо включить параметр клиента "Создание и использование потоков данных". Этот параметр клиента применяется ко всей организации.

Рассмотрим следующий сценарий.

Многие семантические модели в организации должны применять динамические RLS. Для этого требуется, чтобы имена субъектов-пользователей (UPN) хранились в семантической модели (для фильтрации по идентификатору потребителя отчета).
Создатель потока данных, принадлежащий отделу кадров, создает поток данных текущих сведений о сотрудниках, включая их имена участника-пользователя. Они настраивают поток данных для ежедневного обновления.
Создатели семантической модели затем используют поток данных в своих макетах моделей для настройки RLS.

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

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

Определите стратегию разрешений создателя потока данных: определите, какие настройки и требования существуют для управления безопасностью для создателей потоков данных. Рассмотрим, кто разрешен или поощряется, чтобы взять на себя ответственность за управление деятельностью по подготовке данных в централизованных и децентрализованных бизнес-подразделениях.
Решите, кто может создавать потоки данных. Определите, должны ли быть какие-либо ограничения, для которых создатели данных Power BI могут создавать потоки данных. Задайте параметр клиента "Создание и использование потоков данных", чтобы выровнять это решение.
Узнайте, как обрабатываются роли рабочей области для создателей потоков данных: определите, что влияет на процесс разработки рабочей области. Создайте отдельные рабочие области потока данных для каждой области темы, чтобы обрабатывать роли и разрешения рабочей области отдельно для каждой области темы при необходимости.

Разрешения создателя Datamart

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

Datamarts предоставляет простой интерфейс с низким кодом для приема данных из разных источников данных, а также для извлечения, преобразования и загрузки данных с помощью Power Query Online. Данные загружаются в База данных SQL Azure, которая полностью управляется и не требует настройки или оптимизации. Автоматически созданная семантическая модель всегда синхронизирована с управляемой базой данных, так как она находится в режиме DirectQuery.

Вы можете создать datamart, если вы являетесь администратором рабочей области, членом или участник. Роли рабочей области также сопоставляются с ролями уровня базы данных в База данных SQL Azure (однако, так как база данных полностью управляется, разрешения пользователей не могут быть изменены или управляемы в реляционной базе данных).

Параметр клиента Create datamarts позволяет администраторам Power BI настроить, какие группы пользователей могут создавать данные.

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

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

Совместное использование datamart позволяет создателям содержимого:

Создание содержимого с помощью автоматической семантической модели: семантическая модель — это семантический слой, на котором можно создавать отчеты Power BI. Большинство создателей отчетов должны использовать семантику модели.
Подключение и запрашивать База данных SQL Azure: реляционная база данных полезна для создателей содержимого, которые хотят создавать новые семантические модели или отчеты с разбивкой на страницы. Они могут записывать структурированные запросы языка запросов SQL для получения данных с помощью конечной точки SQL.

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

Вы можете определить RLS для datamarts , чтобы ограничить доступ к данным для указанных пользователей. RLS настраивается в редакторе datamart в служба Power BI, и он автоматически применяется к автогенерируемой семантической модели и База данных SQL Azure (как правила безопасности).

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

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

Определите стратегию разрешений создателя datamart: определите, какие настройки и требования существуют для управления безопасностью для создателей datamart. Рассмотрим, кто разрешен или поощряется, чтобы взять на себя ответственность за управление данными в централизованных и децентрализованных бизнес-подразделениях.
Решите, кто может создавать данные. Определите, должны ли быть какие-либо ограничения, для которых создатели данных Power BI могут создать datamart. Задайте параметр клиента Create datamarts, чтобы выровнять это решение. Если вы решите ограничить, кто может создавать данные, рассмотрите возможность использования группы, например утвержденных создателей datamart Power BI.
Просмотрите, как роли рабочей области обрабатываются для создателей datamart: определите, что влияет на процесс разработки рабочей области. Создайте отдельные рабочие области данных для каждой области темы, чтобы роли рабочей области и семантическая модель могли быть упрощены для области темы.
Укажите рекомендации для создателей datamart по управлению разрешениями. Включите документацию для создателей datamart о том, как управлять разрешениями datamart. Опубликуйте эти сведения на централизованный портал и учебные материалы.
Определите стратегию использования RLS в datamarts: рассмотрите варианты использования и цели, которые вы планируете использовать RLS в datamart.

Оценка карта разрешения создателя

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

Оценка карта можно защитить тремя уровнями разрешений:

Рабочая область.
Оценка карта (для каждого элемента) разрешений.
Метрики (в рамках оценки карта).

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

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

Параметр клиента "Создание и использование метрик" позволяет администраторам Power BI настроить, какие группы пользователей могут создавать оценки карта метрики.

Оценка карта разрешения

Вы можете назначить следующую оценку карта разрешения.

Чтение. Это разрешение позволяет пользователю просматривать оценку карта.
Повторное использование: целевой доступ для любого пользователя с существующим разрешением на оценку карта это разрешение позволяет пользователям предоставлять доступ к оценке карта другому пользователю.

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

Разрешения на уровне метрик

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

Роли уровня метрик позволяют задать следующие параметры:

Кто может просматривать отдельные метрики по оценке карта.
Кто может обновлять отдельные метрики следующими способами:
- Обновление состояния во время проверка-в.
- Добавление заметок во время проверка-in.
- Обновление текущего значения во время проверка-в.

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

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

Определите стратегию оценки карта разрешения создателя: определите, какие настройки и требования существуют для управления безопасностью для оценки карта создателей. Рассмотрим, кто разрешен или поощряется, чтобы взять на себя ответственность за управление данными в централизованных и децентрализованных бизнес-подразделениях.
Решите, кто может создавать оценку карта. Определите, должны ли быть какие-либо ограничения, для которых создатели данных Power BI могут создавать оценки карта. Задайте параметр клиента "Создание и использование метрик", чтобы выровнять это решение. Если вы решите ограничить, кто может создавать оценку карта, рассмотрите возможность использования группы, например утвержденной оценки Power BI карта создателей.
Узнайте, как роли рабочей области обрабатываются для оценки карта создателей: определите, что влияет на процесс разработки рабочей области. Рассмотрите возможность создания отдельных рабочих областей для оценки карта когда содержимое охватывает области темы.
Предоставьте рекомендации по оценке карта создателям по управлению разрешениями: включите документацию для оценки карта создателей о том, как управлять разрешениями на уровне метрик. Опубликуйте эти сведения на централизованный портал и учебные материалы.

Публикация содержимого

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

Рабочие области

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

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

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

Синхронизация Power Apps

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

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

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

Доступ к конвейеру развертывания

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

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

Создатели содержимого также могут потребоваться:

Разрешения на создание рабочей области (когда рабочие области необходимо создать конвейером).
Разрешения емкости Premium или Fabric (когда рабочие области назначаются конвейером).

Внимание

Иногда эта статья относится к Power BI Premium или ее подпискам на емкость (SKU). Обратите внимание, что корпорация Майкрософт в настоящее время объединяет варианты покупки и отставает от номера SKU емкости Power BI Premium. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (SKU) вместо этого.

Дополнительные сведения см. в разделе "Важные обновления", поступающие в лицензирование Power BI Premium и вопросы и ответы по Power BI Premium.

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

Конечная точка XMLA

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

Конечная точка XMLA также обеспечивает подключение. Вы можете подключиться только к семантической модели, если в рабочей области установлено значение Premium на пользователя, Premium на емкость или Embedded. После подключения средство, совместимое с XMLA, может работать с моделью данных для чтения или записи данных. Дополнительные сведения об использовании конечной точки XMLA для управления семантической моделью см. в сценарии расширенного управления моделями данных.

Доступ через конечную точку XMLA будет учитывать существующие разрешения. Администраторы рабочей области, члены и участник неявно имеют разрешение на запись семантической модели, что означает, что они могут развертывать новые семантические модели из Visual Studio и выполнять скрипты языка скриптов табличного моделирования (TMSL) в SQL Server Management Studio (SSMS).

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

Разрешить конечные точки XMLA и анализ в Excel с параметром клиента локальных семантических моделей относится к двум возможностям: он определяет, какие группы пользователей могут использовать конечную точку XMLA для запроса и /или поддержания семантических моделей в служба Power BI. Он также определяет, можно ли использовать анализ в Excel с локальными моделями служб SQL Server Analysis Services (SSAS).

Примечание.

Анализ в аспекте Excel этого параметра клиента применяется только к локальным моделям СЛУЖБ SQL Server Analysis Services (SSAS). Стандартный анализ в функции Excel, которая подключается к семантической модели Power BI в служба Power BI, управляется параметром клиента Allow Live Подключение ions.

Публикация в Интернете

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

Внимание

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

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

Внедрение в пользовательские приложения

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

Внедрение в PowerPoint

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

Примечание.

Для работы этой возможности пользователям необходимо установить надстройку Power BI для PowerPoint. Чтобы использовать надстройку, пользователи должны иметь доступ к хранилищу надстроек Office, либо надстройка должна быть доступна для них как управляемая администратором надстройка. Дополнительные сведения см. в надстройке Power BI для PowerPoint.

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

Примечание.

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

Приложения-шаблоны

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

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

Подписки электронной почты

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

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

Внимание

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

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

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

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

Определите стратегию публикации содержимого, каким образом и кем: определите, какие предпочтения и требования существуют для публикации содержимого.
Проверка доступа к рабочей области. Подтвердите подход к проектированию рабочей области. Проверьте, как использовать роли доступа к рабочей области для поддержки стратегии публикации содержимого.
Определите, как обрабатывать разрешения конвейера развертывания. Определите, какие пользователи могут публиковать содержимое с помощью конвейера развертывания. Задайте соответствующие разрешения конвейера развертывания. Убедитесь, что также предоставляется доступ к рабочей области.
Решите, кто может подключаться к семантической модели с помощью конечной точки XMLA: решите, какие пользователи могут запрашивать или управлять семантической моделью с помощью конечной точки XMLA. Задайте конечные точки XMLA и анализируйте в Excel с параметром клиента локальных семантических моделей, чтобы выровнять это решение. Если вы решите ограничить эту возможность, рассмотрите возможность использования группы, например утвержденных создателей содержимого Power BI.
Решите, кто может публиковать отчеты публично: решите, какие пользователи могут публиковать отчеты Power BI публично, если таковые имеются. Задайте параметр "Опубликовать" в веб-клиенте , чтобы выровнять это решение. Используйте группу, например общедоступную публикацию Power BI.
Решите, кто может внедрять содержимое в пользовательские приложения: определите, кто должен быть разрешен для внедрения содержимого за пределами служба Power BI. Задайте для параметра клиента приложения содержимое внедрения, чтобы оно соответствовало этому решению.
Решите, кто может внедрять содержимое в PowerPoint: определите, кто должен быть разрешен для внедрения содержимого в PowerPoint. Задайте для параметра клиента PowerPoint надстройку Enable Power BI, чтобы выровнять это решение.
Определите, кто может публиковать приложения шаблонов: определите, какая стратегия используется для использования приложений-шаблонов за пределами организации. Задайте параметр клиента "Опубликовать приложения шаблона", чтобы выровнять это решение.
Определите, следует ли включать подписки: убедитесь, что ваша стратегия предназначена для использования подписок. Задайте параметр клиента "Подписки электронной почты", чтобы выровнять это решение.

Обновление данных

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

Владелец семантической модели

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

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

Существует два способа получения учетных данных Power BI для обновления семантической модели.

Владелец семантической модели сохраняет учетные данные в параметрах семантической модели.
Владелец семантической модели ссылается на шлюз в параметрах семантической модели (который содержит источник данных с сохраненными учетными данными).

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

Внимание

Использование семантической модели владения окончательно удаляет все сохраненные учетные данные для семантической модели. Учетные данные необходимо повторно ввести для возобновления операций обновления данных.

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

Владелец потока данных

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

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

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

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

Бөлісу құралы:

Планирование реализации Power BI: планирование безопасности создателя содержимого

Стратегия создателей содержимого

Создатели данных

Создатели отчетов

Разрешения для создателей

Создание нового содержимого

Публикация разрешений на содержимое

Обновление данных

Обнаружение содержимого для создателей

Запрос рабочего процесса доступа для создателей

Создание и публикация содержимого

Роли рабочей области

Администратор рабочей области

Член рабочей области

Участник рабочей области

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

Вопросы владения рабочей областью

Варианты ролей рабочей области

Разрешения создателя приложений

Разрешения источника данных

Доступ к источнику данных

Уровни конфиденциальности

Запросы к собственной базе данных

Настраиваемые соединители

Разрешения создателя семантической модели

Разрешения семантической модели

Разрешение на чтение семантической модели

Разрешение на сборку семантической модели

Разрешение на запись семантической модели

Разрешение повторной общей папки семантической модели

Безопасность данных семантической модели

Семантические модели семантики в цепочке

Запросы API семантической модели

Разрешения создателя отчетов

Разрешения на чтение и сборку для базовой семантической модели

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

Подключение для внешних семантических моделей

Рекомендуемые таблицы

Пользовательские разрешения визуальных элементов

Разрешения создателя потока данных

Разрешения создателя Datamart

Общий доступ к Datamart

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

Оценка карта разрешения создателя

Оценка карта разрешения

Разрешения на уровне метрик

Публикация содержимого

Рабочие области

Синхронизация Power Apps

Доступ к конвейеру развертывания

Конечная точка XMLA

Публикация в Интернете

Внедрение в пользовательские приложения

Внедрение в PowerPoint

Приложения-шаблоны

Подписки электронной почты

Обновление данных

Владелец семантической модели

Владелец потока данных

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

Кері байланыс

Кері байланыс

Қосымша ресурстар