« Qui a accès à ce rapport ? » est probablement la question la plus posée par les administrateurs Power BI, et la plus difficile à traiter rapidement.
Entre les rôles au niveau workspace, les partages individuels de rapports et d’applications, les permissions au niveau des lignes (Row-Level Security) et les accès hérités via des groupes Microsoft 365 ou Microsoft Entra ID, la surface à auditer est large et fragmentée.
Ce guide détaille une méthode complète pour mener cet audit sérieusement.
Étape 1 : identifier les quatre couches d’accès à auditer
Les rôles de workspace
Chaque workspace Power BI définit quatre rôles standards :
- Admin,
- Membre,
- Contributeur
- et Lecteur.
L’Admin peut tout modifier, y compris supprimer le workspace lui-même. Un audit doit systématiquement recenser qui détient le rôle Admin sur chaque workspace, car c’est le niveau de risque le plus élevé.
Les partages directs
Indépendamment du rôle de workspace, un rapport ou une application peut être partagé individuellement avec des utilisateurs spécifiques, internes ou parfois externes (invités B2B). Ces partages ponctuels sont la principale source d’accès « oubliés » : accordés pour un besoin temporaire, ils sont rarement révoqués une fois ce besoin disparu.
La sécurité au niveau des lignes (RLS)
Définie dans le modèle sémantique, la RLS filtre les données visibles selon le profil de l’utilisateur connecté (par exemple, un commercial ne voit que les données de sa région).
Un audit doit vérifier non seulement que la RLS existe, mais qu’elle est correctement testée pour chaque
rôle défini : une RLS mal configurée peut laisser filtrer des données non prévues.
L’héritage via les groupes Microsoft 365 / Microsoft Entra ID
De nombreux accès Power BI ne sont pas accordés individuellement mais via l’appartenance à un groupe Microsoft 365. Cet héritage est invisible depuis l’interface Power BI elle-même : il faut croiser les données avec Microsoft Entra ID pour comprendre l’accès réel d’un utilisateur donné.
Étape 2 : utiliser les outils natifs disponibles
Le portail d’administration Power BI (Admin Portal) permet de consulter les rôles de workspace un par un, ainsi que certains paramètres tenant liés au partage externe. L’API Power BI REST, via les endpoints Admin (notamment ceux liés aux workspaces, aux utilisateurs de workspace et aux artefacts), permet d’extraire ces informations de façon plus systématique, mais nécessite un développement pour être exploitable à l’échelle de l’organisation entière, et ne fournit pas de vue consolidée combinant rôles, partages, RLS et héritage de groupes.
Étape 3 : repérer les angles morts fréquents
| Angle mort | Pourquoi il est dangereux | Comment le détecter |
|---|---|---|
| Comptes de service orphelins | Conservent des droits Admin après la fin d’un projet | Croiser la liste des Admins de workspace avec les comptes actifs RH |
| Partages directs oubliés | Accordés à un consultant externe, jamais révoqués | Lister tous les partages individuels par rapport, tous workspaces confondus |
| Groupes M365 trop larges | Des dizaines de personnes accèdent à un rapport sensible sans que cela apparaisse explicitement | Croiser la composition des groupes avec les workspaces auxquels ils sont associés |
| RLS mal testée | Risque de fuite de données selon le profil connecté | Tester chaque rôle RLS avec la fonctionnalité « View As Role » |
| Rôles de workspace qui contournent la RLS | La RLS ne s’applique qu’aux Lecteurs : les Admins, Membres et Contributeurs voient toutes les données | Vérifier que les consommateurs de données sensibles n’ont que le rôle Lecteur |
| Invités externes actifs | Accès B2B non révoqué après la fin d’une collaboration | Filtrer les utilisateurs externes dans les journaux d’accès |
Étape 4 : documenter et répéter l’audit
Un audit d’accès n’a de valeur que s’il est répété régulièrement (idéalement chaque trimestre, ou à chaque changement organisationnel significatif) et documenté pour être présenté lors d’un contrôle de conformité (RGPD, nLPD, ISO 27001, normes sectorielles bancaires ou de santé). Faire cet audit manuellement, workspace par workspace, devient rapidement intenable au-delà de quelques dizaines d’espaces de travail.
Vers une vue consolidée et continue : l’enjeu final n’est pas seulement de pouvoir répondre ponctuellement à un audit annuel, mais de disposer en permanence d’une vue à 360° des permissions, capable de détecter immédiatement un accès anormal (par exemple un nouvel Admin ajouté sur un workspace sensible) plutôt que de le découvrir 6 mois plus tard lors du contrôle suivant.
Cette continuité change fondamentalement la posture de sécurité : on passe d’un contrôle réactif à une supervision proactive.
Questions fréquentes
Combien de temps prend un audit d’accès Power BI complet manuel ?
Pour un tenant d’une cinquantaine de workspaces, un audit manuel rigoureux couvrant les quatre couches d’accès prend généralement plusieurs jours à plusieurs semaines, selon la disponibilité des équipes et la complexité de la RLS en place.
La RLS suffit-elle à garantir la sécurité des données sensibles ?
Non, la RLS filtre l’affichage des données au sein d’un rapport, mais elle ne remplace pas un contrôle d’accès au rapport lui-même. Un utilisateur sans accès au rapport n’a de toute façon aucune donnée à filtrer ; la RLS et les rôles de workspace sont complémentaires, pas substituables.
Comment gérer les accès des utilisateurs externes (invités) ?
Les accès invités doivent faire l’objet d’une revue spécifique et plus fréquente, car ils échappent souvent aux processus RH classiques de désactivation de compte. Un audit doit systématiquement isoler et examiner séparément la liste des comptes externes actifs.
Cet audit d’accès rejoint directement le deuxième signal évoqué dans « Gouvernance Power BI : les 7 signes que votre environnement vous échappe ».
Voir aussi « Inventaire Power BI » pour disposer de la base d’artefacts nécessaire à un audit exhaustif.
