Architecture multilocataire avec des identités de service dédiées

Pour les nouvelles solutions multilocataires, utilisez des applications de service Microsoft Entra dédiées pour les identités client. Lorsque les exigences d’hébergement et de confiance correspondent à votre solution, utilisez des informations d’identification d’identité managée et d’identité fédérée pour authentifier ces applications clientes sans stocker leurs secrets clients ou leurs clés privées de certificat.

Les profils de principal de service restent une solution valide et facultative pour les applications Power BI Embedded nouvelles et existantes dont les exigences correspondent à leurs avantages et limitations. Ils ne sont pas obsolètes. Si votre solution basée sur un profil existant répond à vos besoins, vous pouvez continuer à l’utiliser.

Cet article vous aide à choisir un modèle d’identité et à trouver les instructions de configuration appropriées. Un locataire est un locataire logique ou une limite d’autorisation dans votre application, pas nécessairement un locataire Microsoft Entra distinct.

Modèle recommandé : responsables dédiés du service client

Créez un enregistrement d’application et un principal de service pour chaque périmètre d’autorisation du client. Accordez à ce principal l’accès uniquement aux espaces de travail et ressources autorisés du client. Les principaux de service dédiés fournissent des enregistrements de connexion Microsoft Entra indépendants, l’administration de l’annuaire et l’accès aux services qui prennent en charge ces identités.

Lorsque vous êtes éligible et disposez d’une licence, vous pouvez appliquer l’accès conditionnel de l’identité de charge de travail directement aux principaux de service. La création d’un principal n’accorde pas automatiquement l’accès ou n’active pas une opération d’API non prise en charge. Vérifiez la prise en charge des identités et les exigences d’autorisation de chaque service cible.

Choisir une méthode d’authentification

Le modèle d'authentification recommandé utilise une identité managée affectée par l'utilisateur sur la ressource de calcul Azure prise en charge par l’application en tant que source d’assertion. Les informations d’identification de fédération d’identité sur chaque inscription d’application client font confiance à cette identité managée. Au moment de l’exécution, l’application échange l’assertion d’identité managée contre un jeton d’accès aux ressources représentant le principal de service du client sélectionné.

Ce modèle supprime la nécessité de stocker et de faire pivoter les secrets ou certificats de l’application client. Il n’élimine pas l’inscription des applications, l’administration des relations de confiance, les autorisations de ressources ou la gestion du cycle de vie des identités client.

L’identité managée et les enregistrements d’applications qui lui font confiance doivent appartenir au même locataire d’annuaire Microsoft Entra. Les ressources cibles d’un autre locataire ont des exigences supplémentaires en matière de configuration d’application, de consentement et d’autorisation. L’échange de jetons entre clouds n’est pas pris en charge. Consultez les exigences relatives au modèle et à la confiance.

Si vous ne souhaitez pas utiliser l’identité managée et la fédération, authentifiez les applications clientes dédiées directement avec des certificats ou d’autres informations d’identification d’application prises en charge. Protégez les identifiants stockés et automatisez la rotation des identifiants. Consultez l’alternative d’authentification directe.

Autorisation et montée en charge du plan

Ni les principaux dédiés ni les profils ne créent automatiquement l’isolation cryptographique des clients. Une identité managée de runtime partagé peut s’authentifier en tant que chaque application cliente qui l’approuve. De même, un runtime ayant accès à plusieurs informations d’identification client stockées peut utiliser ces identités. Protégez le runtime et résolvez l’identité du client et les ressources autorisées par le biais de la configuration côté serveur approuvée.

Les autorisations des espaces de travail et des ressources régissent l’accès. Configurez les paramètres de locataire requis et accordez à chaque principal client les rôles de ressources pris en charge les moins privilégiés. Pour les paramètres délimités au groupe, incluez explicitement chaque principal pertinent dans un groupe de sécurité autorisé.

Les identités dédiées consomment des objets d’annuaire Microsoft Entra. Comparez le nombre de clients avec les quotas d’annuaire, les autorisations de provisionnement et le débit, ainsi que les limites de ressources de chaque service. Automatisez l’intégration, la surveillance et le déprovisionnement. Ne sélectionnez pas un modèle d’identité uniquement à partir du nombre d’utilisateurs d’application.

Autre modèle : profils de service principal

Les profils fournissent des contextes clients légers sous un principal de service parent. Vous pouvez créer des profils sans inscription d’application Microsoft Entra distincte pour chaque client. Un parent peut créer jusqu’à 100 000 profils, et chaque profil peut accéder ou créer jusqu’à 1 000 espaces de travail dans les limites documentées.

Les profils peuvent correspondre aux applications qui apprécient ce modèle de mise à l’échelle et d’administration et ne nécessitent pas d’identités Entra indépendantes pour leurs contextes clients. Ils prennent en charge les interfaces REST Power BI documentées, .NET SDK et XMLA/TOM, mais pas les API REST Fabric. Les profils manquent également d’enregistrements de connexion Entra indépendants et d’un accès conditionnel par identité de charge de travail par profil, et restent liés à leur parent.

Un parent d’identité managée peut s’authentifier sans secrets d’application stockés, mais ne transforme pas ses profils en identités Entra indépendantes ou n’étend pas leur prise en charge des API.

Évaluez les avantages et limitations de la solution de profil facultative avant de la choisir. Les espaces de travail clients distincts et les modèles sémantiques peuvent prendre en charge l’un ou l’autre modèle d’identité ; ces avantages de conception de données ne sont pas exclusifs aux profils.

Trouver les conseils d’implémentation appropriés

Utilisez les conseils qui correspondent à votre modèle choisi et à la solution actuelle :

Contenu connexe

• Configurez une application pour faire confiance à une identité managée.
• Microsoft Entra limites de service.
• Accès conditionnel pour les identités de charge de travail.
• Prise en charge des identités de l’API REST dans Fabric.