Comment sécuriser un rapport Power BI : la méthode complète

Pour sécuriser un rapport Power BI, ne vous contentez pas de limiter son lien de partage : contrôlez à la fois qui peut ouvrir le rapport, quelles lignes et colonnes cette personne peut consulter, et ce qu’elle peut ensuite exporter, reconstruire ou partager. La combinaison la plus robuste repose sur un espace de travail réservé aux producteurs, une application destinée aux lecteurs, des groupes d’identité bien gérés et une sécurité RLS testée.

Comprendre les trois couches de sécurité d’un rapport Power BI

Un rapport est la couche de visualisation. Il peut donner accès à un modèle sémantique, à des données importées, à une source en DirectQuery ou à une connexion active vers un autre modèle. Sécuriser uniquement la page du rapport revient donc à verrouiller une porte tout en laissant des accès secondaires ouverts. Une stratégie fiable sépare les autorisations de diffusion, les droits sur les données et les capacités de réutilisation.

• Couche 1 — Accès : qui peut ouvrir le rapport, l’application, l’espace de travail et le modèle sémantique ?
• Couche 2 — Données : une fois connecté, quelles lignes, colonnes, mesures ou tables cette personne peut-elle réellement interroger ?
• Couche 3 — Usages : peut-elle exporter en Excel ou CSV, analyser dans Excel, créer un nouveau rapport, télécharger le fichier PBIX, s’abonner par e-mail ou partager à son tour ?

Avant toute configuration, dessinez un mini-modèle de menace : données salariales, marges, données clients, informations de santé, prévisions ou identifiants internes n’appellent pas tous le même niveau de protection. Listez les populations autorisées, ce qu’elles doivent voir, ce qu’elles peuvent faire, et les conséquences d’un export non maîtrisé. Ce travail évite le réflexe dangereux consistant à donner un accès large « temporaire » qui devient permanent.

Choisir le bon mode de diffusion : espace de travail ou application

L’espace de travail est l’atelier de production : on y publie, modifie, teste et organise les rapports, modèles sémantiques, tableaux de bord et flux éventuels. L’application Power BI est la vitrine : elle fournit aux utilisateurs finaux un point d’entrée stable, avec un contenu et des audiences maîtrisés. Cette distinction réduit fortement le risque de permissions dispersées.

Concrètement, créez des groupes par fonction ou périmètre métier : par exemple « Finance-France-Lecteurs », « Direction-Commerciale » ou « Contrôle-de-gestion-Producteurs ». Évitez d’inscrire directement des dizaines de personnes dans un workspace. La gestion par groupe permet de retirer immédiatement un accès lorsqu’une personne change de poste, sans avoir à rechercher chaque rapport partagé.

Procédure : sécuriser un rapport Power BI de bout en bout

1. 1. Classer les données et définir les populations
   Inventoriez les informations affichées et les sources reliées. Distinguez au minimum les données publiques, internes, confidentielles et très sensibles selon la politique de votre organisation. Pour chaque population, formulez une règle simple : « un responsable ne voit que son périmètre », « la direction voit le consolidé », ou « les RH voient uniquement leur population autorisée ».
2. 2. Séparer le workspace de production des lecteurs
   Créez ou utilisez un espace de travail dédié. Limitez les rôles Admin et Membre à un nombre réduit de responsables identifiés. Donnez le rôle Contributeur aux personnes qui doivent réellement publier. Les lecteurs ne doivent pas recevoir de rôle d’édition par confort : diffusez-leur l’application ou attribuez, si nécessaire, le rôle Viewer.
3. 3. Construire un modèle sémantique qui supporte la sécurité
   Préparez une table de correspondance entre les identités des utilisateurs et leur périmètre : service, région, filiale, portefeuille ou centre de coûts. Reliez-la proprement aux dimensions métier. La sécurité doit être modélisée dans les données, pas simulée par une page masquée, un filtre visible ou un signet.
4. 4. Configurer la RLS et les rôles métier
   Dans Power BI Desktop, créez les rôles et leurs filtres DAX. Pour une règle dynamique, utilisez l’identité de l’utilisateur connecté et une table d’habilitation plutôt qu’une longue liste d’adresses codées en dur. Publiez ensuite le modèle, associez les groupes d’utilisateurs aux rôles dans le service Power BI et vérifiez que les relations propagent les filtres comme prévu.
5. 5. Publier une application avec les bonnes audiences
   Ajoutez uniquement les rapports et éléments validés. Assignez des groupes aux audiences, vérifiez les droits d’accès au modèle sémantique requis par le rapport, puis publiez l’application. Évitez les liens publics, les liens « toute l’organisation » et les invitations nominatives lorsque le contenu est confidentiel.
6. 6. Réduire les possibilités de sortie et de réutilisation
   Déterminez qui peut exporter les données résumées ou sous-jacentes, créer du contenu à partir du modèle grâce au droit Build, utiliser Analyser dans Excel, télécharger le PBIX ou partager le rapport. Retirez ces capacités par défaut, puis ouvrez-les par exception à des groupes clairement définis. Les réglages de locataire doivent être cohérents avec les paramètres du rapport et du modèle.
7. 7. Tester, publier, puis tracer
   Testez avec un compte placé dans chaque groupe métier, pas seulement avec votre compte d’administrateur. Contrôlez les pages, filtres, infobulles, exportations, drill-through et détails sous-jacents. Après la publication, programmez une revue des accès et consultez les journaux d’activité pour détecter les usages anormaux.

Mettre en place une RLS fiable, et savoir quand aller plus loin

La sécurité au niveau des lignes, ou Row-Level Security (RLS), filtre les enregistrements retournés à l’utilisateur. C’est le bon mécanisme lorsqu’un seul rapport doit servir plusieurs régions, clients internes ou managers, chacun avec son périmètre. Une RLS dynamique, fondée sur l’identité de connexion et une table d’habilitation maintenue par le métier, est généralement plus durable que la création d’un rôle par personne.

Surveillez particulièrement les relations plusieurs-à-plusieurs, les relations bidirectionnelles et les tables de sécurité mal reliées : elles peuvent faire remonter plus de données que prévu, ou au contraire tout bloquer. Ne vous fiez pas uniquement au mode « Afficher en tant que » dans Desktop. Il est utile pour valider la logique DAX, mais un test dans le service, avec un vrai groupe et les mêmes droits qu’un utilisateur final, est indispensable.

Réduire les fuites par export, téléchargement et partage

L’exfiltration la plus banale n’est pas une intrusion sophistiquée : c’est souvent un export Excel, un fichier PBIX téléchargé ou un droit Build accordé trop largement. Ces fonctions sont utiles aux analystes, mais elles transforment un rapport contrôlé en données facilement copiables, réutilisables et parfois transférables hors du cadre initial.

• Exports : différenciez l’export de données résumées et l’export de données sous-jacentes. Le second est plus sensible et doit être exceptionnel.
• Droit Build : accordez-le aux analystes autorisés à créer des rapports à partir d’un modèle ; ne le donnez pas automatiquement aux consommateurs.
• Téléchargement : limitez le téléchargement du PBIX aux propriétaires et à une équipe de continuité identifiée. Le fichier peut contenir le modèle et sa logique métier.
• Partage : empêchez les repartages inutiles et privilégiez les groupes. Désactivez les liens de diffusion trop larges lorsque le niveau de confidentialité l’exige.
• Abonnements et alertes : vérifiez les destinataires, car un e-mail contenant un aperçu de données peut devenir un canal de diffusion non contrôlé.

Protégez aussi l’amont. Un rapport importé doit utiliser des identifiants de source gérés de manière centralisée ; aucun mot de passe, jeton ou clé API ne doit être saisi dans une mesure, un paramètre visible ou une requête facilement récupérable. Pour une passerelle de données, appliquez le moindre privilège au compte de service, limitez les administrateurs de la passerelle et révisez les accès aux sources publiées.

Installer une gouvernance durable : tests, audit et réponse aux incidents

La sécurité d’un rapport évolue avec l’organisation : arrivées, départs, changements de région, nouveaux jeux de données, nouveaux responsables et nouvelles fonctions Power BI. Un rapport parfaitement paramétré le jour de sa publication peut devenir risqué quelques mois plus tard si ses groupes ne sont plus maintenus.

1. Documentez le propriétaire : chaque espace de travail, application et modèle sémantique doit avoir un responsable métier et un responsable technique.
2. Planifiez une revue des accès : contrôlez périodiquement les administrateurs, membres, contributeurs, viewers, audiences d’application et groupes RLS.
3. Analysez les traces : exploitez les journaux d’activité Power BI et, selon votre environnement, les capacités d’audit pour repérer partages, exports, téléchargements et changements de droits.
4. Testez après chaque changement : une nouvelle relation, une nouvelle table ou un nouveau visuel de détail peut modifier le périmètre effectivement exposé.
5. Préparez l’incident : sachez qui retire un utilisateur d’un groupe, qui suspend une application, qui vérifie les exports et qui informe les parties concernées.

Enfin, adoptez une règle simple pour les rapports les plus sensibles : deux personnes ou équipes distinctes doivent pouvoir vérifier la publication. L’une produit et met à jour le contenu ; l’autre valide les groupes, la RLS, les exports et le niveau de confidentialité. Ce contrôle croisé est particulièrement utile pour les données financières, RH, clients ou réglementées.