Principal de service Power BI : ouvrir son tenant sans l'exposer

Vous comparez deux portails pour diffuser vos rapports Power BI. Le premier se branche en dix minutes, sans rien vous demander. Le second réclame un groupe de sécurité et deux réglages dans votre tenant. Le premier paraît plus simple, et il vous apprend surtout quelque chose sur votre tenant. Si un service se branche sur votre Power BI sans qu'aucun réglage ne vous soit demandé, ce n'est pas qu'il en a besoin de moins. C'est que votre tenant est déjà ouvert.

Cet article explique ce que cela veut dire, pourquoi c'est fréquent, et comment fermer la porte en une heure sans rien casser. Il vaut pour n'importe quel portail qui diffuse vos rapports Power BI, le nôtre compris.

Ce qu'est un principal de service, et pourquoi il entre chez vous

Dès qu'un portail affiche vos rapports Power BI à des personnes sans licence Pro, il passe par une application Microsoft Entra. Microsoft l'appelle un service principal, en français un principal de service. C'est une identité, comme un compte utilisateur, sauf qu'elle appartient à un logiciel et non à une personne.

C'est le mécanisme de Power BI Embedded : une capacité paie la puissance de calcul, l'application ouvre les rapports, et vos lecteurs n'ont besoin d'aucun compte Microsoft. Rien de suspect là-dedans, c'est la voie prévue par Microsoft pour diffuser à grande échelle sans acheter une licence Pro par lecteur.

La vraie question porte donc sur qui décide quelles applications entrent, et sur l'endroit où se trouve la liste.

Les deux réglages qui décident de tout

Deux paramètres du locataire Power BI tranchent si une application peut diffuser vos rapports. Ils se trouvent dans les paramètres du locataire, sous « Paramètres de développeur ». Microsoft les déplace en ce moment vers OneLake catalog, onglet Govern, puis Configurations : selon votre région, vous les trouverez là ou dans l'ancien portail d'administration.

Le portail n'est pas toujours traduit, et les tutoriels en français non plus. Cherchez-les par leur nom anglais :

• Embed content in apps autorise l'incorporation de rapports Power BI dans une application extérieure à Power BI.
• Service principals can call Fabric public APIs autorise les applications, et non les personnes, à appeler les API Power BI et Fabric. D'anciens tutoriels parlent encore de Allow service principals to use Power BI APIs : c'est l'ancien nom de ce réglage, et la documentation française de Microsoft le montre encore sous ce libellé.

Chacun peut s'appliquer à toute l'organisation, ou à des groupes de sécurité nommés. Il existe aussi des variantes avec exclusion (« toute l'organisation sauf tel groupe »), mais pour notre sujet, seules les deux premières positions comptent.

Un détail pèse lourd. Selon la documentation Microsoft des réglages développeur, Service principals can call Fabric public APIs est activé par défaut pour les nouveaux clients. Autrement dit, beaucoup de tenants sont ouverts sans que personne ne l'ait décidé.

Pourquoi tant de tenants restent ouverts

Le scénario typique n'a rien d'une négligence. Un ancien projet a demandé d'ouvrir les deux réglages, un consultant l'a fait sur « toute l'organisation » parce que c'était plus rapide, et personne n'y est revenu. Deux ans plus tard, le tenant héberge trente espaces de travail et une dizaine d'applications que plus personne ne sait relier à un contrat.

Dans cet état, une application n'a besoin que de deux choses pour lire vos rapports : être autorisée dans l'annuaire, et être ajoutée à un espace. Aucun réglage Power BI ne la retient.

Tenant ouvert ou restreint : la comparaison

Le surcoût du tenant restreint se mesure en une heure, une fois. Le gain se mesure le jour où quelqu'un vous demande qui lit vos données.

Ce qu'un tenant ouvert expose vraiment

Le risque, c'est l'absence de liste. Dans l'entreprise, personne ne peut dire avec certitude quelles applications lisent vos rapports Power BI.

Toute application de l'annuaire peut appeler les API : une application installée pour un autre usage, un essai oublié, un connecteur qu'un collaborateur a autorisé un vendredi soir. Dès qu'elle est membre d'un espace, elle lit ses rapports et ses modèles.

L'incorporation est ouverte à tous, ce qui veut dire que n'importe quel utilisateur peut afficher vos rapports dans un outil extérieur sans passer par l'informatique.

Un oubli ne se voit pas. Le jour où vous quittez un prestataire, rien ne vous rappelle que son application lit encore trois de vos espaces.

Et l'audit devient long. Pour répondre à « qui accède à nos données Power BI ? », il faut parcourir chaque espace de travail un par un, noter les membres, et deviner ce qu'est chaque application.

Microsoft le dit d'ailleurs dans sa page sur l'incorporation avec un principal de service : « Les principaux de service ont accès à tous les paramètres du locataire pour lesquels ils sont autorisés. En fonction de vos paramètres d'administrateur, cela comprend des groupes de sécurité spécifiques ou toute l'organisation. » La même page recommande d'autoriser l'accès uniquement à des groupes de sécurité spécifiques.

Pour des rapports qui portent du chiffre d'affaires, des marges, de la masse salariale ou des données clients, cette liste fermée est exactement ce que demandera un commissaire aux comptes, un auditeur RGPD ou un client grand compte. Nous détaillons les autres volets de la protection dans notre article sur la sécurité des données dans Power BI.

La configuration recommandée, pas à pas

C'est la forme que Microsoft recommande, et celle que les réglages supposent. Comptez une heure la première fois, avec un administrateur Microsoft Entra et un administrateur Power BI (parfois la même personne dans une PME).

1. Créer un groupe de sécurité dédié dans Microsoft Entra, par exemple « Power BI - Applications autorisées ». Un seul groupe pour tous vos services tiers suffit. Inutile d'en créer un par prestataire : c'est le groupe qui sert de liste.
2. Y ajouter l'application du prestataire. Depuis portal.azure.com : ouvrez le groupe, puis Membres, puis Ajouter un membre, et cherchez l'application par son nom. Le centre d'administration Microsoft 365 ne propose pas toujours les applications dans ce sélecteur, d'où le détour par le portail Azure.
3. Limiter les deux réglages à ce groupe. Dans les paramètres du locataire Power BI, passez Embed content in apps et Service principals can call Fabric public APIs sur « Groupes de sécurité spécifiques », et choisissez votre groupe. Si d'autres usages internes en dépendent, un script d'export ou une application maison, ajoutez leurs groupes plutôt que de rouvrir à tous.
4. Ajouter l'application aux seuls espaces à diffuser, avec le rôle Membre. Microsoft exige Membre ou Administrateur pour qu'une application serve un rapport, et Membre suffit. N'ajoutez jamais l'application à un espace « au cas où » : c'est ce geste, espace par espace, qui décide de ce qu'elle lit.
5. Attendre la propagation. Selon la page Microsoft sur les paramètres du locataire, un changement peut mettre jusqu'à quinze minutes à s'appliquer. Un service qui échoue juste après n'est pas forcément mal configuré.

Attention à l'ordre de bascule si votre tenant est déjà ouvert et que des services y tournent. Mettez d'abord toutes les applications légitimes dans le groupe, ensuite seulement restreignez les réglages. Dans l'ordre inverse, chaque application oubliée tombe en panne pendant que vous cherchez laquelle.

Deux réglages Entra à regarder au passage

Tant que vous êtes dans Microsoft Entra, deux paramètres méritent un regard, à valider avec votre administrateur : qui peut inscrire des applications, et qui peut donner son accord à une application. Dans beaucoup d'annuaires, un utilisateur ordinaire peut encore faire l'un ou l'autre.

Les réserver aux administrateurs ferme la porte par laquelle une application entre sans que personne ne l'ait décidé. C'est un sujet plus large que Power BI, que nous abordons dans notre article sur Microsoft Entra et le contrôle du locataire.

Et la sécurité au niveau des lignes ?

Si certains rapports sont filtrés par ligne (RLS), par exemple un responsable d'agence qui ne voit que son agence, la règle ne change pas. C'est le portail qui transmet l'identité du lecteur à Power BI au moment où il ouvre le rapport. L'application elle-même ne voit pas « tout » à la place du lecteur : elle demande à Power BI un affichage au nom de quelqu'un.

Demandez à votre prestataire comment il le fait. Et testez-le avec un compte sans licence avant de diffuser.

Contrôler et révoquer

Une fois le groupe en place, garder la maîtrise demande peu de temps. Le geste principal est trimestriel : relire le groupe. Chaque membre doit correspondre à un contrat en cours, et une application sans contrat en sort, même si « elle ne fait rien ».

À côté, la page Applications d'entreprise de Microsoft Entra donne la liste de tout ce qui a reçu un accord dans votre annuaire, avec la date et la personne qui l'a donné. C'est là que vous retrouvez l'essai d'il y a deux ans que tout le monde avait oublié.

Pour l'activité réelle, le journal d'activité Power BI, dans le portail Microsoft Purview, rubrique Audit, trace les consultations, y compris celles qui passent par une application.

Les questions à poser à tout prestataire Power BI

Ces questions valent pour n'importe quel service qui se branche sur votre Power BI, y compris Drivn. Une réponse vague vaut une réponse négative.

La question sur la licence partagée mérite qu'on s'y arrête. Certains outils affichent vos rapports en se connectant avec un seul compte Pro au nom de tous vos lecteurs. C'est moins cher sur le papier, mais Microsoft ne l'autorise pas, et vous perdez toute traçabilité de qui a vu quoi. Nous comparons les modèles de diffusion dans notre guide pour partager des rapports Power BI.

Ce que fait Drivn de son côté

Nous nous appliquons le tableau ci-dessus. Notre portail de diffusion Power BI fonctionne avec un tenant restreint, et c'est la forme que recommande notre procédure de connexion d'un espace : le groupe de sécurité, les deux réglages limités à ce groupe, le rôle Membre sur les seuls espaces à diffuser. Rien de plus.

Quand un réglage manque, l'écran de vérification dit lequel. Si les réglages sont limités à un groupe dont l'application n'est pas membre, Power BI renvoie la même erreur que si le réglage était fermé. Nous distinguons les deux cas en demandant à Microsoft la liste des espaces où l'application est présente. Vous pouvez aussi apporter votre propre application Entra, si votre politique exige que l'identité qui lit vos espaces vous appartienne.

Pour les équipes informatiques qui encadrent ce type de projet, notre page DSI et notre page sécurité des données détaillent l'hébergement et les sous-traitants.

Liste de contrôle

Avant de mettre un service tiers en production sur votre Power BI, cochez chaque ligne.

• Un groupe de sécurité dédié existe dans Microsoft Entra.
• L'application du prestataire en est membre, et seuls les services tiers sous contrat y figurent.
• Embed content in apps est limité à ce groupe, et aux groupes internes qui en ont besoin.
• Service principals can call Fabric public APIs est limité au même groupe.
• L'application n'est membre que des espaces à diffuser, avec le rôle Membre.
• L'inscription d'applications et l'accord des utilisateurs ont été tranchés avec l'administrateur Entra.
• Les modèles filtrés par ligne ont été testés avec un compte sans licence.
• La procédure de retrait du prestataire est écrite et rangée.
• Une revue trimestrielle du groupe est au calendrier.

Neuf lignes, une heure de travail, et une réponse nette le jour où l'on vous demande qui lit vos chiffres. Pour le reste de la gouvernance du tenant, licences, utilisateurs et workspaces, notre guide d'administration Power BI prend le relais.