Vise à restreindre l'accès à certaines pages entières d'un rapport Power BI en fonction de l'utilisateur.
Power BI ne propose pas de fonctionnalité native et prête à l'emploi pour la PLS. Ce que nous allons apprendre est une solution de contournement ingénieuse, un "hack", qui utilise d'autres fonctionnalités de Power BI pour atteindre cet objectif.
Cas d'usage
Prenons l'exemple d'une entreprise fictive qui utilise un rapport Power BI pour suivre ses performances commerciales. Ce rapport contient :
Une "Page d'Accueil" (visible par tous les employés) Une page "Synthèse des Ventes Régionales" (qui devrait être visible uniquement par les managers et le directeur commercial) Une page "Détails des Commissions Individuelles" (qui devrait être accessible seulement au directeur commercial) Les vendeurs individuels, quant à eux, ne devraient voir que la "Page d'Accueil". La PLS nous permet d'adapter l'affichage du rapport à chaque profil utilisateur, garantissant que chacun accède uniquement aux informations qui lui sont pertinentes.
3. Mise en Œuvre de la PLS : Un Guide Pas à Pas (La "Méthode du Formateur")
Pour mettre en place cette PLS, nous allons combiner la Sécurité au Niveau des Lignes (RLS), des sélecteurs (slicers) et des boutons de navigation.
Étape 1 : Création d'une Table de Sécurité des Pages (Votre "Annuaire" des Accès)
Créez une nouvelle table dans Power BI Desktop (vous pouvez l'appeler TableSecurite ou Permission). Elle doit contenir au moins deux colonnes : UtilisateurEmail : Les adresses e-mail de tous les utilisateurs. PageAutorisee : Les noms des pages auxquelles chaque utilisateur doit avoir accès. Exemple pour Acme Corp : | UtilisateurEmail | PageAutorisee | | :----------------------- | :-------------------- | | manager1@acme.com | Accueil | | manager1@acme.com | SyntheseVentes | | dir.commercial@acme.com | Accueil | | dir.commercial@acme.com | SyntheseVentes | | dir.commercial@acme.com | DetailsCommissions | | vendeur1@acme.com | Accueil | Chargez cette table dans votre modèle Power BI. Étape 2 : Création de Rôles Utilisateurs avec la Sécurité au Niveau des Lignes (RLS)
Allez dans l'onglet "Modélisation" de Power BI Desktop et cliquez sur "Gérer les rôles". Cliquez sur "Créer" et donnez un nom à votre rôle (par exemple, "UtilisateurReport"). Sous "Sélectionner des tables", choisissez votre TableSecurite. Appliquez un filtre à la colonne UtilisateurEmail en utilisant la fonction DAX USERPRINCIPALNAME(). La formule sera : 'TableSecurite'[UtilisateurEmail] = USERPRINCIPALNAME(). Cette fonction récupère automatiquement l'adresse e-mail de l'utilisateur connecté à Power BI, garantissant que chaque utilisateur ne voit que les lignes (et donc les pages autorisées) qui lui sont attribuées. Cliquez sur "Enregistrer". Étape 3 : Le Sélecteur et les Boutons de Navigation (Votre "Menu Personnalisé")
Créez une page "Accès Refusé" : Ajoutez une page dédiée affichant un message comme "Vous n'avez pas l'autorisation de consulter cette page". Créez une mesure DAX de navigation pour chaque page sensible : Par exemple, pour la page "Synthèse des Ventes Régionales" : Nav_SyntheseVentes = IF( "SyntheseVentes" IN VALUES('TableSecurite'[PageAutorisee]), "Synthèse des Ventes Régionales", "Accès Refusé" ). Répétez pour "Détails des Commissions Individuelles" : Nav_DetailsCommissions = IF( "DetailsCommissions" IN VALUES('TableSecurite'[PageAutorisee]), "Détails des Commissions Individuelles", "Accès Refusé" ). Placez des boutons de navigation sur votre "Page d'Accueil" : Pour chaque page que vous voulez sécuriser (ex: "Synthèse des Ventes Régionales", "Détails des Commissions Individuelles"), insérez un bouton. Sélectionnez un bouton, allez dans le panneau "Format", puis "Action". Définissez le "Type" sur "Navigation de page". Pour la "Destination", utilisez le formatage conditionnel (cliquez sur "fx"). Sélectionnez "Valeur de champ" comme "Style de formatage" et choisissez la mesure DAX de navigation correspondante (ex: Nav_SyntheseVentes). Étape 4 : Masquer les Pages et Ajouter un Bouton "Retour" (La "Discrétion")
Masquez toutes les pages du rapport (sauf la "Page d'Accueil" et la page "Accès Refusé"). Cela empêche les utilisateurs de voir la liste complète des pages dans la navigation standard de Power BI. Sur chaque page masquée et la page "Accès Refusé", ajoutez un bouton "Retour" qui ramène l'utilisateur à la "Page d'Accueil". Étape 5 : Test et Vérification (La "Preuve par l'Exemple")
Dans Power BI Desktop, sous l'onglet "Modélisation", cliquez sur "Voir comme". Sélectionnez le rôle "UtilisateurReport" que vous avez créé et entrez une adresse e-mail d'un utilisateur de votre TableSecurite (ex: vendeur1@acme.com). Le vendeur devrait uniquement voir les boutons menant à des pages autorisées (ici, la "Page d'Accueil"). S'il clique sur un bouton pour une page non autorisée, il devrait être redirigé vers la page "Accès Refusé". Testez avec le "dir.commercial@acme.com" pour vérifier qu'il accède à toutes les pages qui lui sont permises. Étape 6 : Publication et Partage Sécurisé (La "Mise à Disposition")
Publiez votre rapport sur le service Power BI (dans un espace de travail approprié). Dans le service Power BI, accédez à l'espace de travail où vous avez publié le rapport. À côté de votre modèle sémantique, cliquez sur les trois petits points (...), puis sur "Sécurité". Assignez les utilisateurs et/ou les groupes de sécurité Microsoft Entra (ex: "Groupe des Managers", "Groupe des Vendeurs") à votre rôle "UtilisateurReport". 4. Limites et Précautions : Ce que vous Devez Absolument Savoir
Bien que cette méthode soit efficace, il est crucial d'être conscient de ses limitations, car elle ne représente pas une "vraie" sécurité au niveau des pages. C'est davantage de la "sécurité par l'obscurité" :
Pas de Support Natif : Comme mentionné, c'est une solution de contournement, pas une fonctionnalité intégrée de Power BI. Accès Via URL : C'est la limitation la plus critique ! Si un utilisateur non autorisé obtient l'URL directe d'une page masquée (par exemple, quelqu'un d'autorisé lui envoie le lien), il pourra y accéder. Le masquage des pages n'empêche pas un accès direct si l'URL est connue. Maintenance Accrue : La gestion de nombreux rôles, de mesures de navigation et de la visibilité des boutons peut devenir complexe et chronophage, surtout si la structure du rapport change fréquemment ou si vous avez un grand nombre d'utilisateurs et de rôles. Expérience Utilisateur : Cette approche peut ajouter des étapes de navigation, ce qui pourrait légèrement impacter la fluidité pour l'utilisateur. Problèmes avec les Fonctionnalités Avancées : La PLS pourrait ne pas fonctionner comme prévu avec des fonctionnalités comme le "Drill-through" (extraction de détails). Impact sur les Performances : L'utilisation intensive de logiques conditionnelles et de navigation dynamique peut, dans certains cas, affecter les performances du rapport. 5. Conseils Pratiques pour une PLS Plus Robuste
Pour minimiser les risques liés à cette méthode de contournement :
Masquez toujours les pages que vous souhaitez restreindre, en dehors de la page d'accueil. N'envoyez jamais de liens directs vers des pages spécifiques à vos utilisateurs. Envisagez les "Rapports Mince" (Thin Reports) et les Audiences d'Applications : Pour une sécurité plus robuste, surtout dans les grandes organisations, une approche courante consiste à créer des "rapports minces". Chaque page de votre rapport d'origine devient un rapport Power BI distinct. Ces rapports "minces" se connectent tous au même modèle sémantique. Vous les regroupez ensuite dans une application Power BI, et utilisez la fonctionnalité "Audiences" pour définir quels rapports (qui représentent vos pages d'origine) sont visibles pour quels groupes d'utilisateurs. Cela offre une meilleure granularité de contrôle à grande échelle. La Sécurité au Niveau des Objets (OLS) : Le Garde du Corps du Contenu : Pour une véritable protection des données sensibles, même si une page est contournée via son URL, il est fortement recommandé de combiner la PLS avec la Sécurité au Niveau des Objets (OLS). L'OLS permet de restreindre l'accès à des tables, colonnes ou mesures spécifiques. Ainsi, même si un utilisateur non autorisé accède à une page (par exemple, "Détails des Commissions Individuelles"), les visuels affichant des données sensibles (comme la colonne "Montant Commission") seront vides ou afficheront un message d'erreur, car la colonne leur sera invisible. L'implémentation de l'OLS nécessite l'utilisation d'outils tiers comme Tabular Editor et un espace de travail Power BI Premium. 6. Conclusion : Vers une Gestion des Accès Optimisée
La mise en œuvre de la PLS dans Power BI est un défi important pour les organisations soucieuses de la confidentialité des données et de l'accès basé sur les rôles. Bien qu'il s'agisse actuellement d'une solution de contournement, elle permet de créer une expérience de rapport personnalisée et sécurisée pour vos utilisateurs.
En tant que formateur, j'espère que ces explications vous ont donné les clés pour comprendre et implémenter cette technique avec discernement. N'oubliez jamais les limites, surtout le risque de contournement par URL, et envisagez des solutions complémentaires comme les "rapports minces" avec les audiences d'applications et l'OLS pour une sécurité renforcée. Nous espérons tous que Microsoft intégrera un jour cette fonctionnalité nativement pour simplifier encore davantage la gestion des accès.
"Page Level Security"