Планирование реализации 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.
• Создатели семантической модели, которые хотят использовать существующую семантику для новой составной модели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учетные данные шифруются и хранятся отдельно от модели данных в 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 Query, можно использовать собственный запрос для доступа к данным. Собственный запрос — это инструкция, написанная на языке, поддерживаемом источником данных. Собственные запросы поддерживаются только определенными источниками данных, которые обычно являются реляционными базами данных, такими как База данных SQL Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создатели отчетов нуждаются в доступе к рабочей области для создания отчетов в служба 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 Desktop создатели семантической модели могут задать таблицу моделей, чтобы стать рекомендуемой таблицей. Когда семантическая модель публикуется в служба Power BI, создатели отчетов могут использовать коллекцию типов данных в Excel для поиска рекомендуемой таблицы, позволяя им добавлять рекомендуемые данные таблицы для расширения своих листов Excel.

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

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

Помимо основных визуальных элементов создатели отчетов 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 Desktop может отображать предупреждение системы безопасности при добавлении пользовательского визуального элемента в отчет. Создатели отчетов могут отключить этот параметр. Этот параметр не проверяет, сертифицирован ли визуальный элемент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Системы показателей можно защитить с тремя уровнями разрешений:

• Рабочая область.
• Разрешения системы показателей (на элемент).
• Метрики (в системе показателей).

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

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

Параметр клиента "Создание и использование метрик" позволяет администраторам 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 (когда рабочие области назначаются конвейером).

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

Конечная точка 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).

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

Публикация в Интернете — это функция, которая предоставляет доступ к отчетам 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. При необходимости включите этот параметр для определенных групп, таких как создатели отчетов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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