Профили служебных объектов для многопользовательских приложений в Power BI Embedded

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

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

Участник-служба приложения ISV создает отдельный профиль Power BI для каждого клиента или арендатора. Когда клиент посещает приложение ISV, приложение использует соответствующий профиль для создания токена встраивания, который используется для отображения отчета в браузере.

Использование профилей субъекта-службы позволяет приложению ISV размещать несколько клиентов в одном клиенте Power BI. Каждый профиль представляет одного клиента в Power BI. Другими словами, каждый профиль создает и управляет содержимым Power BI для данных одного конкретного клиента.

Настройка содержимого Power BI включает следующие действия.

• Создание профиля
• Настройка разрешений профиля
• Создание рабочей области для каждого клиента
• Импорт отчетов и семантических моделей в рабочую область
• Задайте параметры подключения семантической модели для соединения с данными клиента
• Удаление разрешений субъекта-службы (необязательно, но помогает с масштабируемостью)
• Внедрение отчета в приложение

Все описанные выше действия можно полностью автоматизировать с помощью REST API Power BI.

Предварительные условия

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

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

Создание профиля

С помощью REST API профилей можно создавать, обновлять и удалять профили.

Например, чтобы создать профиль:

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

Субъект-служба также может вызвать REST API профилей, чтобы получить список своих профилей. Например:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Разрешения профиля

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

При использовании профилей важно понимать следующие моменты:

• Профиль принадлежит субъекту-службе, создавшего его, и только этот субъект-служба может использовать его.
• Владелец профиля не может быть изменен после создания.
• Профиль не является автономной личностью. Для вызова REST API Power BI требуется токен субъекта-службы Microsoft Entra.

Приложения ISV вызывают REST API Power BI, указывая в заголовке Authorization токен учетной записи службы Microsoft Entra, а в заголовке X-PowerBI-Profile-Id — идентификатор профиля. Например:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Создание рабочей области

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

Каждому профилю нужно:

• Создание по крайней мере одной рабочей области Power BI

  POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXA…ZUiIsg
  Content-Type: application/json; charset=utf-8
  X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
  
  {
    "name": "ContosoWorkspace"
  }
  

• Предоставьте разрешения на доступ к рабочей области. Профиль учётной записи службы должен иметь доступ администратора к рабочей области.

• Назначение рабочей области емкости

  POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/AssignToCapacity HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
  Content-Type: application/json; charset=utf-8
  X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
  
  {
    "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
  }
  

Дополнительные сведения о рабочих областях Power BI.

Импорт отчетов и семантических моделей

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

POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

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

Настройка подключения семантической модели

Поставщики программного обеспечения обычно хранят данные своих клиентов одним из двух способов:

• Отдельная база данных для каждого клиента
• Одна мультитенантная база данных

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

Отдельная база данных для каждого клиента

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

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

• Обновление API источника данных: создайте .pbix, указывающий на источник данных с образцом данных. Затем импортируйте .pbix в рабочую область клиента и измените параметры подключения с помощью Update Datasource API.

Одна мультитенантная база данных

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

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

Вставить отчет

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

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

Чтобы создать токен внедрения:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Аспекты проектирования

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

• Масштабируемость
• Автоматизация и сложность эксплуатации
• Много-географические потребности
• Экономичность
• Безопасность на уровне строк

Масштабируемость

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

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

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

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

Автоматизация и операционная сложность

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

• Добавление нового клиента
• Обновление отчета для некоторых или всех клиентов
• Обновление схемы семантической модели для некоторых или всех клиентов
• Включение незапланированных настроек для конкретных клиентов
• Настройка частоты обновления семантической модели

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

Потребности Multi-Geo

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

По соображениям соответствия требованиям может потребоваться создать несколько клиентов Power BI в разных регионах. Дополнительные сведения о multi-geo.

Рентабельность

Разработчикам приложений, использующим Power BI Embedded, необходимо приобрести емкость Power BI Embedded. Модель разделения на основе профилей хорошо работает с емкостями, так как:

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

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

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

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

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

• Им нужно поддерживать только один отчет и одну семантическую модель.
• Процесс подключения для новых клиентов можно упростить

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

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

Рекомендации и ограничения

• Профили учетных записей служб поддерживаются только через REST API Power BI, SDK для Power BI .NET, а также через конечную точку XMLA и табличную объектную модель (TOM) при использовании клиентских библиотек служб Analysis Services версии 16.0.139.27 или более поздней. Профили субъектов-служб не поддерживаются в Power BI через конечную точку XMLA или табличную объектную модель (TOM) с более старыми клиентскими библиотеками.
• Профили учетных записей служб не поддерживаются в Azure Analysis Services (AAS) в режиме прямого подключения.
• Максимальное количество профилей, которое может иметь один сервисный принципал, составляет 100 000.

Ограничения емкости Power BI

• Каждая емкость может использовать только выделенную память и виртуальные ядра в соответствии с приобретенным номером SKU. Рекомендуемый размер семантической модели для каждого SKU смотрите в разделе Большие семантические модели Premium.
• Чтобы использовать семантическую модель размером более 10 ГБ, используйте емкость Premium и включите параметр больших семантических моделей .
• Количество обновлений, которые могут выполняться одновременно в рамках емкости, ссылается на управление ресурсами и оптимизацию.

Управление субъектами-службами

Изменение субъекта-службы

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

Удаление субъекта-службы

Если удалить учетную запись обслуживающего приложения в Active Directory, все его профили в Power BI удаляются. Однако Power BI не удаляет содержимое немедленно, поэтому администратор клиента по-прежнему может получить доступ к рабочим областям. Будьте осторожны при удалении субъекта-службы, используемого в рабочей системе, особенно при создании профилей с помощью этого субъекта-службы в Power BI. При удалении учетной записи службы, которая создала профили, необходимо заново создать все профили, предоставить новым профилям доступ к соответствующим рабочим пространствам и обновить идентификаторы профилей в базе данных приложений ISV.

Разделение данных

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

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

• Человеческая ошибка или утечка учетных данных не приведут к утечке данных нескольких клиентов.
• Смена сертификатов может выполняться отдельно для каждого клиента.

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

Один отчет, несколько семантических моделей

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

Настройка и создание содержимого

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

Управляемое системой удостоверение

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

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

• Если управляемое удостоверение, назначаемое системой, случайно отключено, вы потеряете доступ к профилям. Эта ситуация аналогична случаю, когда удаляется служебный принципал.
• Управляемое удостоверение, назначаемое системой, подключено к ресурсу в Azure (веб-приложение). При удалении ресурса удостоверение также удаляется.
• Использование нескольких ресурсов (разных веб-приложений в разных регионах) приводит к нескольким удостоверениям, которым необходимо управлять отдельно (у каждого удостоверения есть собственные профили).

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

Пример

Для примера того, как использовать профили субъектов-служб для управления мультитенантной средой с встраиванием Power BI и App-Owns-Data, скачайте репозиторий App Owns Data Multitenant с Power BI Dev Camp (сторонний сайт).

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

• Использование SDK Power BI с сервисными учетными записями
• Перенос мультитенантных приложений в модель профилей учетных записей служебных принципалов
• Разработка масштабируемых мультитенантных приложений с помощью внедрения Power BI