Поделиться через

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

  • Статья

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

Примечание.

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

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

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

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

Схема профилей sp и мультитенантности.

Примечание.

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

Настройка содержимого 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, чтобы получить список его профилей. Например:

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, предоставляя токен 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/f313e682-c86b-422c-a3e2-b1a05426c4a3/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/f313e682-c86b-422c-a3e2-b1a05426c4a3/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 в рабочую область клиента и измените сведения о подключении с помощью API update Datasource.

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

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

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

Внедрение отчета в Power BI Embedded

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

Когда клиент посещает приложение, используйте соответствующий профиль для вызова 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 рабочими областями. Чтобы преодолеть это ограничение, субъект-служба может создавать несколько профилей, где каждый профиль может получить доступ к рабочим областям до 1000 рабочих областей. С несколькими профилями приложение ISV может изолировать содержимое каждого клиента с помощью отдельных логических контейнеров.

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

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

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

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

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

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

Потребности с несколькими регионами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предупреждение

Будьте очень осторожны при удалении субъекта-службы. Вы не хотите случайно потерять данные со всех связанных профилей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

Пример использования профилей субъектов-служб для управления мультитенантной средой с помощью внедрения Power BI и App-Owns-Data скачайте мультитенантный репозиторий данных приложения из Power BI Dev Camp (сторонний сайт).

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