Thème 2 — Sécurisation et gestion des accès
Informations générales
| Durée | 2h30 (pause incluse) |
| Positionnement | Jour 1 — Séquence 3 (après-midi) |
| Public visé | Administrateurs Power BI, équipes DSI, référents BI |
| Prérequis | Maîtrise de Power BI Desktop, notions de modélisation, compte Power BI Pro actif |
| Matériel requis | Power BI Desktop installé, accès Power BI Service, jeu de données d’exercice |
Objectifs pédagogiques
À l’issue de cette séquence, les participants seront capables de :
- Comprendre les principes du Row-Level Security (RLS) et ses cas d’usage
- Implémenter un RLS statique avec des rôles manuels dans Power BI Desktop
- Configurer un RLS dynamique avec les fonctions DAX USERPRINCIPALNAME() et USERNAME()
- Tester la sécurité des données via la fonction « afficher en tant que » dans le Service
- Gérer les rôles utilisateurs et les droits d’accès dans l’espace de travail
- Exploiter les outils d’audit : journal d’activités, métriques d’utilisation, alertes
Déroulement détaillé de la séquence
Partie 1 — Principes du Row-Level Security (20 min)
Contenu à présenter
- Définition du RLS : mécanisme de filtrage des données au niveau des lignes, appliqué selon le rôle de l’utilisateur connecté
- Différence entre sécurité au niveau des lignes (RLS) et sécurité au niveau des objets (OLS)
- Cas d’usage typiques : données régionales, données par département, données confidentielles par équipe
- Architecture : les rôles sont définis dans Desktop, les membres sont assignés dans le Service
- Fonctionnement avec Import vs DirectQuery
Conseils formateur
💡 Commencer par un scénario concret : « Un directeur régional ne doit voir que les données de sa région. Comment faire ? » Laisser les participants proposer des solutions avant d’introduire le RLS.
⚠️ Point de vigilance : bien expliquer que le RLS ne s’applique pas aux administrateurs de l’espace de travail (rôle Admin/Member). Seuls les rôles Viewer sont soumis au RLS.
Partie 2 — RLS statique (30 min)
Contenu à présenter
- Création de rôles dans Power BI Desktop : onglet Modélisation > Gérer les rôles
- Syntaxe des filtres DAX pour les rôles : [Région] = "Nord", [Département] = "Finance"
- Appliquer un filtre sur une table de dimension qui se propage aux tables de faits via les relations
- Tester localement dans Desktop avec la fonctionnalité « Afficher en tant que rôle »
- Limites du RLS statique : chaque combinaison nécessite un rôle dédié, maintenance lourde
Travaux pratiques
TP — Créer un RLS statique régional
- Ouvrir le fichier Power BI Desktop fourni contenant un modèle Ventes avec une table Dimension_Région
- Créer trois rôles : « Nord », « Sud », « Est » avec des filtres DAX sur la colonne [Région]
- Tester chaque rôle localement via « Afficher en tant que »
- Vérifier que les visuels (graphiques, tableaux) se filtrent correctement selon le rôle
Conseils formateur
💡 Démonstration en direct recommandée. Montrer d’abord le résultat attendu (un visuel filtré) avant de passer à la création du rôle. Faire le TP en même temps que les participants.
Partie 3 — RLS dynamique (30 min)
Contenu à présenter
- Principe du RLS dynamique : un seul rôle qui s’adapte automatiquement à l’utilisateur connecté
- Fonction USERPRINCIPALNAME() : retourne l’adresse e-mail de l’utilisateur (Azure AD/Entra ID)
- Fonction USERNAME() : retourne le nom d’utilisateur (format domaine\utilisateur ou UPN)
- Expression DAX type : [Email_Responsable] = USERPRINCIPALNAME()
- Nécessité d’une table de correspondance utilisateur ↔ périmètre (table de sécurité)
- Avantage : scalabilité, un seul rôle à maintenir quel que soit le nombre d’utilisateurs
Travaux pratiques
TP — Mettre en place un RLS dynamique
- Ajouter une table Sécurité_Utilisateurs avec les colonnes [Email] et [Région]
- Créer une relation entre Sécurité_Utilisateurs[Région] et Dimension_Région[Région]
- Créer un rôle unique « RLS_Dynamique » avec le filtre : [Email] = USERPRINCIPALNAME()
- Tester avec « Afficher en tant que » en saisissant différentes adresses e-mail
- Comparer avec le RLS statique : avantages et inconvénients
Conseils formateur
⚠️ Préciser que USERPRINCIPALNAME() ne fonctionne pas en local dans Desktop (retourne vide). Il faut utiliser « Afficher en tant que → Autre utilisateur » pour simuler. En production, la fonction retourne automatiquement l’e-mail de l’utilisateur connecté.
Partie 4 — Test et déploiement du RLS dans le Service (20 min)
Contenu à présenter
- Publication du rapport avec les rôles RLS vers l’espace de travail
- Attribution des membres aux rôles dans le Service : Sécurité > Row-Level Security
- Test avec la fonction « Afficher en tant que » dans le Service
- Impact sur le partage : un rapport partagé avec RLS filtre automatiquement les données
- Combinaison RLS + rôles de l’espace de travail : matrice des droits effectifs
Partie 5 — Gestion avancée des rôles et droits d’accès (20 min)
Contenu à présenter
- Rappel des 4 rôles de l’espace de travail : Admin, Membre, Contributeur, Lecteur
- Matrice des permissions par rôle : qui peut publier, modifier, partager, exporter
- Bonnes pratiques : principe du moindre privilège, attribution par groupes de sécurité Azure AD
- Gestion des accès via les applications Power BI : audiences et permissions granulaires
- Scénarios DSI : séparation des environnements Dev / Test / Prod avec des pipelines de déploiement
Conseils formateur
💡 Proposer un exercice de mise en situation : distribuer des fiches de rôle (admin, contributeur, lecteur) et demander aux participants de déterminer les actions autorisées. Crée de l’interaction et ancre les concepts.
Partie 6 — Audit et surveillance des activités (20 min)
Contenu à présenter
- Journal d’activités unifié : accès via le portail d’administration Power BI
- Types d’événements tracés : consultation, export, partage, modification, suppression
- Métriques d’utilisation des rapports : nombre de vues, utilisateurs uniques, tendances
- Configuration des alertes : seuils de données, notifications par e-mail
- Bonnes pratiques d’audit : fréquence de revue, rapports de conformité, RGPD
- Intégration avec Microsoft Purview pour une gouvernance avancée
Conseils formateur
💡 Si le temps le permet, montrer en direct le journal d’activités dans le portail d’administration. Sinon, préparer des captures d’écran. Insister sur l’importance de l’audit pour la conformité RGPD.
Synthèse et évaluation (10 min)
- Tour de table rapide : chaque participant cite un point clé retenu
- Quiz de validation des acquis (5 questions sur le RLS, les rôles, l’audit)
- Questions / réponses ouvertes
- Présentation des ressources complémentaires Microsoft Learn
Ressources de référence
- Row-Level Security dans Power BI — Microsoft Learn
- USERPRINCIPALNAME() — Référence DAX Microsoft
- Journal d’audit Power BI — Microsoft Learn
- Rôles de l’espace de travail — Microsoft Learn
- Microsoft Purview et Power BI — Microsoft Learn