Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Sécurité au niveau des lignes dans Power BI et Fabric : comment DAX, rôles et groupes décident vraiment qui voit quoi (Doublage IA)

Transcript

Sécurité au niveau des lignes dans Power BI et Fabric : comment DAX, rôles et groupes décident vraiment qui voit quoi (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

• 0:00
  Speaker 2: Prêt pour 10 jours consacrés à Microsoft 365, Copilot, l'IA
• 0:04
  Speaker 2: Azure et aux acteurs qui façonnent l'avenir du travail. Et
• 0:08
  Speaker 2: en janvier prochain, la M365Con est de retour et nous
• 0:11
  Speaker 2: voyons plus grand. Rejoignez-nous pour des sessions en direct, des
• 0:14
  Speaker 2: démos concrètes et des connaissances pratiques partagées par des MVP
• 0:17
  Speaker 2: et experts mondiaux. Fini les présentations génériques. Fini les mots
• 0:20
  Speaker 2: à la mode interminable. Nous abordons les vrais défis. Copilot Studio,
• 0:24
  Speaker 2: Agents IA Fabrique, Sécurité, Gouvernance et Automatisation. Que vous soyez
• 0:30
  Speaker 2: professionnel IT, développeur ou dirigeant, des sessions sont conçues pour vous.
• 0:35
  Speaker 2: Avec 10 jours complets, explorez de multiples technologies et connectez-vous
• 0:39
  Speaker 2: à une communauté mondiale. Suivez en direct et rapportez des
• 0:42
  Speaker 2: idées pratiques à votre organisation. Janvier 2027, 10 jours, une
• 0:46
  Speaker 2: seule communauté Microsoft. Les inscriptions sont ouvertes. Réservez votre place
• 0:52
  Speaker 2: dès aujourd'hui. Rendez-vous sur m365. net. Inscrivez-vous sur m365un. net et nous
• 1:02
  Speaker 2: nous retrouverons en janvier.
• 1:05
  Speaker 3: Vous êtes-vous déjà demandé qui peut réellement voir vos données
• 1:07
  Speaker 3: dans Power BI? Spoiler, ce n'est pas aussi privé que
• 1:09
  Speaker 3: vous le pensez, sauf si vous maîtrisez la sécurité au
• 1:11
  Speaker 3: niveau des lignes. Dans cet épisode, nous ne nous contentons
• 1:14
  Speaker 3: pas de cocher la case RLS, nous analysons les rouages,
• 1:17
  Speaker 3: les définitions de rôle aux expressions d'axes qui décident discrètement
• 1:20
  Speaker 3: qui voit quoi. La plupart s'arrêtent à la configuration, mais
• 1:23
  Speaker 3: nous vous montrerons comment chaque décision s'articule pour que vos
• 1:26
  Speaker 3: données soient sécurisées par l'architecture et pas seulement verrouillées. Et...
• 1:30
  Speaker 3: Pourquoi la sécurité au niveau des lignes est un système,
• 1:32
  Speaker 3: pas une simple case à cocher? Si vous avez l'habitude
• 1:34
  Speaker 3: de protéger un tableur sensible avec un mot de passe,
• 1:37
  Speaker 3: vous savez déjà qu'il y a un fossé entre votre
• 1:38
  Speaker 3: intention et la protection réelle de vos données. Power BI
• 1:43
  Speaker 3: avec la sécurité au niveau des lignes peut donner exactement
• 1:45
  Speaker 3: la même impression. Vous activez le bouton RLS, assignez quelques
• 1:48
  Speaker 3: rôles et pensez être protégé. Mais en réalité, c'est différent.
• 1:52
  Speaker 3: Les données sensibles s'échappent lorsque les liens entre rôles, filtres
• 1:55
  Speaker 3: et utilisateurs ne sont pas soigneusement définis. On parle rarement
• 1:59
  Speaker 3: de ces moments où un membre de l'équipe commerciale ouvre
• 2:01
  Speaker 3: un tableau de bord et accède à des chiffres qu'il
• 2:03
  Speaker 3: n'aurait jamais dû voir. Pourtant, cela arrive presque toujours à
• 2:08
  Speaker 3: cause de l'idée reçue que la RLS est juste une
• 2:10
  Speaker 3: case de plus à cocher. Mettez-vous à la place de
• 2:13
  Speaker 3: celui qui donne accès à un tableau de bord en
• 2:15
  Speaker 3: pensant simplement aider un collègue. Cela semble inoffensif. Mais dans
• 2:19
  Speaker 3: trop d'organisations, l'accès à un tableau de bord donne accès
• 2:22
  Speaker 3: à tout ce qui se cache derrière. J'ai vu des
• 2:24
  Speaker 3: environnements où un simple rôle de gestionnaire global permettait par
• 2:27
  Speaker 3: erreur à des utilisateurs juniors de consulter des données RH confidentielles,
• 2:30
  Speaker 3: car les noms ne correspondaient pas à la réalité. Et
• 2:33
  Speaker 3: ce n'est pas un cas isolé. C'est plus proche de
• 2:35
  Speaker 3: la règle que de l'exception, surtout quand une entreprise se
• 2:37
  Speaker 3: développe et que les tableaux de bord se multiplient. Tout
• 2:40
  Speaker 3: le monde veut aller vite, mais quand on avance sans structure,
• 2:42
  Speaker 3: on laisse derrière soi de minuscules failles qui peuvent devenir
• 2:45
  Speaker 3: des gouffres lors d'un audit. Sur le papier, la RLS
• 2:48
  Speaker 3: semble un peu plus simple. Créer un rôle, appelons le
• 2:51
  Speaker 3: back-up and support, ajouter un filtre du type région égale,
• 2:53
  Speaker 3: USA égale, USA avec EB, affectez-y des utilisateurs. Mais derrière
• 2:57
  Speaker 3: chaque menu déroulant et chaque case à cocher dans Power BI,
• 2:59
  Speaker 3: un système décide quelles données vont où. Si vous oubliez
• 3:03
  Speaker 3: une relation ou si un filtre n'inclut pas une nouvelle
• 3:05
  Speaker 3: source de données, ce n'est pas juste une erreur technique,
• 3:08
  Speaker 3: c'est un incident de sécurité en puissance
• 3:11
  Speaker 3: Vous ne le saurez pas tant que quelqu'un ne tombera
• 3:12
  Speaker 3: pas sur des données qu'il n'est pas censé voir, et
• 3:14
  Speaker 3: parfois même pas, à ce moment-là. Et c'est ce qui
• 3:16
  Speaker 3: rend ces petites erreurs si difficiles à détecter. Elles ne
• 3:19
  Speaker 3: déclenchent pas d'alerte! Et les audits standards ne vont souvent
• 3:22
  Speaker 3: pas assez loin pour les repérer. Ce qui est négligé,
• 3:25
  Speaker 3: c'est à quel point les composants de la RLS sont
• 3:28
  Speaker 3: étroitement liés. La plupart des tutoriels survolent la configuration vous
• 3:31
  Speaker 3: guidant à travers la création de rôles et les bases
• 3:33
  Speaker 3: des filtres. Ils montrent comment mapper des utilisateurs et cocher
• 3:36
  Speaker 3: une case de prévisualisation. Mais personne ne prend le temps
• 3:38
  Speaker 3: de s'interroger sur l'impact d'un filtre sur la table des ventes,
• 3:41
  Speaker 3: par exemple sur une table de territoire associée, par exemple.
• 3:44
  Speaker 3: Chaque élément de logique dans la RLS se répercute sur
• 3:46
  Speaker 3: les autres, les affectations, les expressions d'axes et même le
• 3:49
  Speaker 3: nommage des rôles eux-mêmes. Si vous traitez ces choix comme
• 3:52
  Speaker 3: des étapes isolées, vous faites confiance au système en espérant
• 3:55
  Speaker 3: qu'il n'y ait pas de faille. Mais avec un seul
• 3:57
  Speaker 3: filtre oublié, votre configuration minutieuse devient soudainement une passoire. C'est
• 4:01
  Speaker 3: l'un de ces domaines où la bonne analogie n'est pas
• 4:04
  Speaker 3: celle d'une porte verrouillée. C'est un réseau de fils entremêlés.
• 4:09
  Speaker 3: Si vous changez une pièce, c'est tout l'ensemble qui peut basculer.
• 4:12
  Speaker 3: Manquez un fil et vous avez créé une fuite qui
• 4:13
  Speaker 3: n'est même pas évidente jusqu'à ce qu'elle soit exploitée. Des
• 4:16
  Speaker 3: incidents réels montrent comment cela se produit. Les témoignages d'équipes
• 4:19
  Speaker 3: analytiques racontent le moment où le responsable des ventes européennes
• 4:22
  Speaker 3: est tombé sur les données du pipeline nord-américain. Ce n'était
• 4:26
  Speaker 3: pas une intrusion mais un filtre mal appliqué, un paramètre
• 4:28
  Speaker 3: par défaut involontaire ou un rôle que personne n'avait pensé
• 4:30
  Speaker 3: à vérifier. Il ne s'agit pas seulement d'histoires d'horreur vécues.
• 4:35
  Speaker 3: Les rapports de vulnérabilité de Microsoft listent la sécurité au
• 4:37
  Speaker 3: niveau des lignes mal configurées comme l'une des principales causes
• 4:40
  Speaker 3: d'exposition publique de données embarrassantes dans les grandes organisations européennes.
• 4:45
  Speaker 3: Pour chaque gros titre sur une faille majeure, il y
• 4:46
  Speaker 3: en a des dizaines qui ne sont pas signalées mais
• 4:48
  Speaker 3: qui ont des conséquences durables en coulisses. Ce qui relie
• 4:52
  Speaker 3: ces problèmes, c'est le faux sentiment de sécurité que la
• 4:54
  Speaker 3: RLS offre lorsqu'on la traite comme une simple tâche à
• 4:58
  Speaker 3: cocher sur une liste. Les études des équipes de sécurité
• 5:01
  Speaker 3: de Microsoft soulignent que la superposition de filtres leur cumule
• 5:04
  Speaker 3: entre les tables, l'application d'expressions d'axes supplémentaires ou l'utilisation de
• 5:07
  Speaker 3: logiques statiques et dynamiques combinées augmentent à la fois la
• 5:10
  Speaker 3: protection et la complexité aux complexités. Chaque couche ajoutée ne
• 5:14
  Speaker 3: renforce pas seulement la sécurité, elle multiplie les points où
• 5:17
  Speaker 3: une erreur de configuration peut se produire. Au lieu d'un
• 5:22
  Speaker 3: simple garde à la porte, vous avez un réseau complexe
• 5:24
  Speaker 3: où un« ne oublier» peut compromettre des mois de planification.
• 5:29
  Speaker 3: Ne négligeons pas non plus les réalités pratiques. Un système
• 5:33
  Speaker 3: peut fonctionner en test … Mais une fois en production,
• 5:36
  Speaker 3: avec de l'utilisateur et des équipes changeantes, vous vous retrouvez
• 5:40
  Speaker 3: avec des anciens hommes employés ayant encore accès aux chiffres financiers.
• 5:48
  Speaker 3: Les noms et les attributions qui semblaient logiques au début
• 5:50
  Speaker 3: deviennent de mystérieux vestiges du passé et du passé. Personne
• 5:53
  Speaker 3: n'ose y toucher, de peur qu'ils ne soient encore utilisés.
• 5:56
  Speaker 3: Si vous activez simplement la RLS lors de la configuration
• 5:58
  Speaker 3: sans suivi, vous ne protégez pas vos données. Vous espérez
• 6:01
  Speaker 3: juste que personne ne frappera la mauvaise porte, par curiosité?
• 6:04
  Speaker 3: ou par erreur. Tout cela nous conduit à une vérité essentielle,
• 6:08
  Speaker 3: la sécurité au niveau des lignes vivantes. Elle évolue avec
• 6:10
  Speaker 3: votre organisation. Chaque rôle créé, chaque filtre d'axe appliqué, chaque
• 6:14
  Speaker 3: groupe assigné, ce ne sont pas des choix anodins. Ils
• 6:17
  Speaker 3: forment un système de protection dynamique, ou, s'ils sont ignorés,
• 6:20
  Speaker 3: un filet rempli de trous. Avant de passer au tableau
• 6:23
  Speaker 3: de bord suivant, ou de transmettre un modèle, demandez-vous, est-ce
• 6:25
  Speaker 3: que je gère vraiment un système de sécurité, ou est-ce
• 6:28
  Speaker 3: que j'espère simplement que l'interrupteur suffit? La suite de cette
• 6:31
  Speaker 3: histoire commence par l'élément central, la logique de filtrage elle-même
• 6:36
  Speaker 3: et comment elle oriente toutes vos décisions à un. Bâtir
• 6:41
  Speaker 3: une base sécurisée, filtrage des données et conception des rôles.
• 6:44
  Speaker 3: Si vous avez déjà configuré la sécurité au niveau des
• 6:46
  Speaker 3: lignes en pensant qu'il ne s'agissait que de masquer certaines lignes,
• 6:48
  Speaker 3: vous n'êtes pas seul. La raison principale pour laquelle la
• 6:50
  Speaker 3: RLS devient complexe est un simple malentendu. Il ne s'agit
• 6:53
  Speaker 3: pas seulement de ce qui est visible mais de façonner
• 6:54
  Speaker 3: toute expérience utilisateur. Info pas rapide et soudain ce... tableau
• 7:01
  Speaker 3: de bonus confidentiel où ce salaire de direction apparaît dans
• 7:03
  Speaker 3: le tableau de bord de quelqu'un. Mais les gens découvrent
• 7:07
  Speaker 3: ces fuites alors que les rapports circulent déjà. Et à
• 7:09
  Speaker 3: ce stade, faire marche arrière est délicat. Le plus gênant,
• 7:13
  Speaker 3: c'est que ces failles semblent rarement spectaculaires. C'est souvent un
• 7:15
  Speaker 3: cas limite, un manager américain se connecte et voit ce
• 7:17
  Speaker 3: qu'il doit voir. Mais un collègue à Londres ouvre le
• 7:20
  Speaker 3: même modèle et découvre, sans que personne ne s'en aperçoive,
• 7:22
  Speaker 3: les chiffres de New York Line. Prenons le lancement d'un
• 7:27
  Speaker 3: modèle fabrique pour les ventes mondiales. Vous voulez que les
• 7:30
  Speaker 3: managers de différentes régions ne voient que leurs propres données.
• 7:33
  Speaker 3: Le réflexe est d'ajouter un filtre, quelque chose de simple.
• 7:36
  Speaker 3: Région égale Etats-Unis ou pays égale Royaume-Uni. Mais voici le piège.
• 7:41
  Speaker 3: La manière dont vous rédigez ce filtre et l'intégrer à
• 7:43
  Speaker 3: votre modèle détermine si votre système tiendra la route ou
• 7:46
  Speaker 3: s'effondrera dès que les choses se complexifieront. Beaucoup pensent que
• 7:49
  Speaker 3: c'est très simple, un filtre d'axe d'une ligne et passe
• 7:52
  Speaker 3: à autre chose. Mais toutes les fonctions d'axe ne se
• 7:55
  Speaker 3: comportent pas de la même manière. En fait, ces nuances
• 7:57
  Speaker 3: cassent souvent tout plus tard, surtout lors du passage de
• 7:59
  Speaker 3: Power BI Desktop à Fabric, où des particularités liées au
• 8:02
  Speaker 3: cloud commencent à apparaître. La sécurité au niveau des lignes
• 8:05
  Speaker 3: RNS devient très vite complexe dès qu'on entend les détails.
• 8:08
  Speaker 3: Les gens se fient souvent à des fonctions comme UserNameHug
• 8:10
  Speaker 3: ou UserPrincipalNameHug, en supposant qu'elles font la même chose ou
• 8:13
  Speaker 3: en choisissant celles utilisées dans un article de blog. Mais
• 8:16
  Speaker 3: remplacez UserNameHug, qui récupère votre nom Windows sur Desktop, par UserPrincipalNameHug,
• 8:21
  Speaker 3: qui récupère votre adresse e-mail sur Fabric, et soudain, votre
• 8:23
  Speaker 3: logique de filtre devient instable. Si un test a fonctionné
• 8:27
  Speaker 3: sur desktop mais a échoué après la publication sur Fabric,
• 8:29
  Speaker 3: c'est probablement la raison. Et un mauvais choix, c'est ainsi
• 8:33
  Speaker 3: que des failles s'ouvrent discrètement, donnant aux mauvaises personnes accès
• 8:36
  Speaker 3: à des données qu'elles ne devraient jamais voir. Entrons dans
• 8:38
  Speaker 3: les détails. Pour des scénarios basiques, une vérification codée en
• 8:41
  Speaker 3: dur fonctionne. Région égale USQMS signifie que seules les lignes
• 8:46
  Speaker 3: où la région et US1K s'affichent, c'est la définition même
• 8:49
  Speaker 3: de la RSTATI. C'est rapide, simple et pour des divisions
• 8:51
  Speaker 3: fixes comme un rapport destiné uniquement aux managers américains, cela
• 8:54
  Speaker 3: suffit amplement, cela suffit amplement. Mais dès que quelqu'un demande
• 8:56
  Speaker 3: une sécurité dynamique, la donne change. Vous pourriez avoir besoin
• 8:59
  Speaker 3: de déterminer l'accès non seulement en fonction du visualiseur de rapport,
• 9:01
  Speaker 3: mais aussi via des relations dans une autre table, une
• 9:02
  Speaker 3: table d'accès utilisateur, par exemple, listant les régions accessibles par
• 9:04
  Speaker 3: chaque utilisateur, par exemple, listant les régions accessibles par chaque utilisateur. Désormais,
• 9:08
  Speaker 3: votre filtre RLS n'est plus une valeur fixe. C'est une
• 9:11
  Speaker 3: formule qui recherche en temps réel les régions auxquelles chaque
• 9:13
  Speaker 3: personne doit accéder. C'est là que le DAX peut vous
• 9:16
  Speaker 3: piéger si vous ne faites pas attention. Vous pourriez opter
• 9:18
  Speaker 3: pour K-user principal name et guider, et essayer de le
• 9:21
  Speaker 3: joindre à votre table d'accès. Mais si votre DAX repose
• 9:24
  Speaker 3: sur des colonnes calculées ou intègre une logique qui ne
• 9:26
  Speaker 3: répond pas au contexte de l'utilisateur au moment de la consultation,
• 9:29
  Speaker 3: vous pouvez accidentellement casser le filtre dynamique. Exemple concret, une
• 9:35
  Speaker 3: entreprise configure un filtre dynamique basé sur une colonne calculée
• 9:38
  Speaker 3: dans sa table de faits pour réaliser plus tard que
• 9:40
  Speaker 3: ces colonnes sont évaluées au chargement des données et non
• 9:43
  Speaker 3: lors de leur consultation. Cela signifie que les utilisateurs ne
• 9:47
  Speaker 3: voient pas leurs lignes personnalisées, ou pire, qu'ils en voient trop.
• 9:51
  Speaker 3: Vous ne vous en rendez compte que lorsqu'un utilisateur vous
• 9:52
  Speaker 3: demande pourquoi un rapport s'affiche différemment pour lui que pour
• 9:54
  Speaker 3: un autre membre de son équipe. La documentation Microsoft et
• 9:58
  Speaker 3: de nombreux blocs de MVP ne cessent de le répéter.
• 10:01
  Speaker 3: Ne faites pas confiance aux colonnes calculées pour la RLS.
• 10:05
  Speaker 3: Les colonnes calculées sont figées lors de l'actualisation. Elles ne
• 10:07
  Speaker 3: changent pas selon l'utilisateur. Pour que la RLS réponde réellement
• 10:10
  Speaker 3: à l'utilisateur, votre logique de filtrage doit être construite via
• 10:13
  Speaker 3: une expression DAX sur des tables mises à jour dans
• 10:15
  Speaker 3: le contexte du rapport. Si vous ignorez cela, vos tableaux
• 10:19
  Speaker 3: de bord vous trahiront discrètement en affichant les mêmes lignes,
• 10:21
  Speaker 3: peu importe qui est connecté. La distinction entre RLS statique
• 10:25
  Speaker 3: et dynamique n'est pas seulement technique. Il s'agit de savoir
• 10:28
  Speaker 3: quand et comment les données sont filtrées. Une RLS statique
• 10:32
  Speaker 3: est rapide et rigide, idéale quand vous savez à l'avance
• 10:35
  Speaker 3: quel rôle a besoin de quelles données. Si vous lancez
• 10:39
  Speaker 3: un rapport uniquement pour un groupe financier ou commercial, cela fonctionne,
• 10:42
  Speaker 3: cela fonctionne. Mais avec une approche dynamique, chaque décision d'accès
• 10:45
  Speaker 3: se prend à la volée, généralement en faisant correspondre l'identité
• 10:48
  Speaker 3: de l'utilisateur actuel à une entrée dans une table de permission.
• 10:52
  Speaker 3: Cette flexibilité est puissante, surtout pour les grandes organisations ou
• 10:55
  Speaker 3: les déploiements multilocataires, mais chaque gain en flexibilité ajoute de
• 10:58
  Speaker 3: la complexité. Et la complexité comporte toujours des risques cachés.
• 11:02
  Speaker 3: Même les administrateurs avancés se font piéger en pensant que
• 11:05
  Speaker 3: les filtres sont toujours simples. La structure réelle de votre
• 11:08
  Speaker 3: organisation change constamment et vos filtres d'axes doivent suivre le rythme.
• 11:12
  Speaker 3: Beaucoup échouent car ils ne réalisent pas que la logique
• 11:14
  Speaker 3: RLS ne s'applique pas au chargement des données, mais à
• 11:17
  Speaker 3: chaque interaction de l'utilisateur avec le rapport. Mais, mais avec
• 11:20
  Speaker 3: le rapport. Si vous oubliez cela, vous pourriez accidentellement ouvrir
• 11:23
  Speaker 3: ou bloquer des pans entiers de votre modèle de données
• 11:25
  Speaker 3: sans vous en rendre compte. En résumé, si les bases
• 11:28
  Speaker 3: sont mauvaises, tout ce que vous construirez avec la RLS
• 11:31
  Speaker 3: n'aura aucune importance. La manière dont vous écrivez votre DAX,
• 11:35
  Speaker 3: le type de filtre utilisé et l'endroit où vous les appliquez,
• 11:37
  Speaker 3: tout cela façonne votre véritable posture de sécurité. Négligez ces
• 11:41
  Speaker 3: nuances essentielles. Vous aboutirez à une configuration qui fonctionne en théorie,
• 11:44
  Speaker 3: mais qui fut en pratique. Tout cela se produit avant
• 11:46
  Speaker 3: même d'en arriver à l'affectation des utilisateurs aux rôles, ce
• 11:49
  Speaker 3: qui s'avère être la prochaine étape où les choses dérapent discrètement.
• 11:52
  Speaker 3: Affecter des rôles aux utilisateurs, le piège de l'assignation. Vous
• 11:55
  Speaker 3: avez donc configuré vos rôles, créé vos filtres, et tout
• 11:57
  Speaker 3: semble bien verrouillé côté modèle. Étape suivante, l'affectation des utilisateurs
• 12:02
  Speaker 3: sans délit d'identes, mais c'est là que la plupart des
• 12:04
  Speaker 3: plans de sécurité au niveau des lignes commencent à se fissurer.
• 12:07
  Speaker 3: C'est le carrefour de la réflexion informatique... La logique technique
• 12:11
  Speaker 3: est en place, mais vous pariez désormais sur le fait
• 12:13
  Speaker 3: que la couche humaine, vos affectations d'utilisateurs et de groupes,
• 12:15
  Speaker 3: correspond réellement à la réalité de votre entreprise. Cela semble simple,
• 12:19
  Speaker 3: car il y a un champ de groupe et une
• 12:21
  Speaker 3: liste de rôles, mais l'expérience montre que c'est là que
• 12:23
  Speaker 3: les erreurs aiment se cacher. Imaginez ceci. Vous avez créé
• 12:26
  Speaker 3: un rôle de manager, vous avez appliqué votre filtre soigneusement conçu,
• 12:29
  Speaker 3: et avez mappé ce rôle dans Power BI ou fabriqué
• 12:31
  Speaker 3: un groupe Azure AD appelé Managers Ugo. Vous vérifiez deux fois,
• 12:37
  Speaker 3: demandez peut-être un second avis, puis vous le déployez dans
• 12:38
  Speaker 3: toute l'organisation. Correct. Au début, cela semble simple. C'est justement
• 12:42
  Speaker 3: là le problème, car la logique de groupe, surtout dans
• 12:44
  Speaker 3: les grandes organisations, reste rarement simple longtemps. Les équipes bougent,
• 12:48
  Speaker 3: les départements se réorganisent, les rôles évoluent, les gens quittent
• 12:51
  Speaker 3: un projet pour en joindre un autre. Que se passe-t-il
• 12:53
  Speaker 3: si quelqu'un passe des ventes aux opérations sans que personne
• 12:55
  Speaker 3: ne nettoie les anciennes appartenances au groupe? Soudainement, votre schéma
• 12:58
  Speaker 3: RLS parfaitement étanche place un utilisateur à deux endroits à
• 13:01
  Speaker 3: la fois. Et il existe un risque réel qu'il accède
• 13:05
  Speaker 3: à des données qui ne le concernent plus à... Il
• 13:07
  Speaker 3: est facile de supposer que chaque membre d'un groupe Azure
• 13:09
  Speaker 3: AD doit bénéficier du même accès. Mais en réalité, les
• 13:12
  Speaker 3: appartenances au groupe peuvent vite devenir obsolètes. Quelqu'un peut être
• 13:15
  Speaker 3: transféré dans une autre région sans que son nom ne
• 13:17
  Speaker 3: soit jamais retiré de la liste de l'équipe initiale. Même si,
• 13:21
  Speaker 3: en tant qu'administrateur, vous êtes très rigoureux sur le nettoyage,
• 13:23
  Speaker 3: les propriétaires de groupe suivent rarement chaque changement, surtout durant
• 13:27
  Speaker 3: un trimestre chargé. N'oubliez pas non plus que la synchronisation
• 13:31
  Speaker 3: entre Azure AD et Power BI ou Fabric n'est pas
• 13:32
  Speaker 3: toujours instantanée. Elle accuse parfois plusieurs heures de retard, ce
• 13:35
  Speaker 3: qui est largement suffisant pour que quelqu'un voit ce qu'il
• 13:37
  Speaker 3: ne devrait pas après un changement. Attendez un traitement de nuit,
• 13:41
  Speaker 3: et un employé sur le départ peut partir avec beaucoup
• 13:43
  Speaker 3: plus d'informations que prévu. Les attributions fantômes peuvent sembler dramatiques,
• 13:48
  Speaker 3: mais elles sont presque routinières. Dans la plupart des environnements réels,
• 13:52
  Speaker 3: un même utilisateur peut facilement se retrouver dans plusieurs groupes,
• 13:54
  Speaker 3: chacun associé à différents rôles RLS. La conception se veut flexible,
• 13:58
  Speaker 3: ce qui est une bonne chose en théorie. En pratique,
• 14:00
  Speaker 3: cela signifie jongler avec un réseau d'autorisations héritées, où il
• 14:03
  Speaker 3: n'est pas toujours clair de savoir qui voit quoi sans
• 14:05
  Speaker 3: une recherche manuelle. Par exemple, si Sarah quitte la finance
• 14:09
  Speaker 3: pour les RH et que personne ne la retire du
• 14:11
  Speaker 3: groupe finance, elle porte deux casquettes, une actuelle et une obsolète.
• 14:15
  Speaker 3: La plupart des gens ne s'en aperçoivent même pas jusqu'à
• 14:17
  Speaker 3: ce que Sarah tente d'accéder à un rapport destiné à
• 14:20
  Speaker 3: la finance et y parvienne encore longtemps après son transfert.
• 14:24
  Speaker 3: Les équipes de sécurité de Microsoft citent les erreurs d'attribution
• 14:27
  Speaker 3: de rôle comme la première cause d'exposition accidentelle de données
• 14:30
  Speaker 3: dans les environnements analytiques. Le calcul est simple. Plus il
• 14:33
  Speaker 3: y a de groupes et d'utilisateurs mobiles, plus il est
• 14:36
  Speaker 3: facile de perdre de vue qui est réellement attaché à
• 14:39
  Speaker 3: chaque rôle. Ce qui rend la chose plus insidieuse, c'est
• 14:42
  Speaker 3: l'absence de retour évident. Contrairement à d'autres erreurs de sécurité,
• 14:45
  Speaker 3: vous n'obtenez aucun message d'erreur ni rupture dans l'interface utilisateur.
• 14:49
  Speaker 3: Il n'y a généralement ni avertissement automatisé, ni examen forcé
• 14:52
  Speaker 3: et un mappage incorrect peut rester dans l'ombre pendant des
• 14:54
  Speaker 3: mois ne faisant surface que lors d'un audit ou si
• 14:56
  Speaker 3: quelqu'un tombe sur des données qu'il n'aurait pas dû toucher.
• 14:59
  Speaker 3: Même les meilleures intentions finissent par s'effriter face aux réalités
• 15:02
  Speaker 3: du quotidien. La révision des appartenances au groupe est une
• 15:04
  Speaker 3: bonne pratique recommandée par tous, mais peu d'équipes l'appliquent avec rigueur.
• 15:09
  Speaker 3: Du point de vue de l'administration, c'est un travail fastidieux.
• 15:12
  Speaker 3: Les révisions manuelles des groupes ne sont pas une priorité absolue,
• 15:15
  Speaker 3: surtout si l'équipe analytique doit gérer d'autres urgences. Dans la
• 15:19
  Speaker 3: plupart des organisations, aucun processus d'audit régulier n'est en place,
• 15:22
  Speaker 3: car on suppose que les changements RH se répercuteront automatiquement.
• 15:26
  Speaker 3: Mais ce sont précisément ces suppositions qui permettent aux permissions
• 15:28
  Speaker 3: de dérivés et aux accès fantômes de subsister. Résultat, avec
• 15:32
  Speaker 3: le temps, votre modèle RLS, aussi précis soit-il sur le papier,
• 15:36
  Speaker 3: se désynchronise de la réalité des accès. Les outils d'audit
• 15:40
  Speaker 3: automatisés aident à détecter ces attributions persistantes, mais leur mise
• 15:43
  Speaker 3: en place demande du travail. Ils doivent se connecter à
• 15:46
  Speaker 3: votre Azure AD, signaler les changements et parfois déclencher un
• 15:49
  Speaker 3: flux de travail si les groupes d'un utilisateur ne correspondent
• 15:51
  Speaker 3: plus à son unité. Tous les environnements Power BI ne
• 15:55
  Speaker 3: disposent pas de tel contrôle, surtout dans les petites structures
• 15:57
  Speaker 3: ou les projets au délaisséré. Ainsi, la prolifération des groupes
• 16:01
  Speaker 3: devient inévitable. Plus votre système RLS stagne, plus les permissions
• 16:04
  Speaker 3: risquent de devenir obsolètes ou, pire, de se propager vers
• 16:07
  Speaker 3: des couches non surveillées. Ce qui surprend vraiment, c'est de
• 16:11
  Speaker 3: réaliser que les attributions ne sont pas qu'une simple formalité.
• 16:14
  Speaker 3: Elles constituent le lien continu qui unit votre logique de
• 16:16
  Speaker 3: sécurité aux utilisateurs réels. Laissez les dérivés et aucun contrôle
• 16:20
  Speaker 3: d'accès intelligent ne pourra vous sauver. L'hygiène des attributions est
• 16:23
  Speaker 3: un processus actif, pas une configuration ponctuelle. Les systèmes évoluent,
• 16:26
  Speaker 3: les utilisateurs bougent, votre modèle doit suivre ses changements sinon
• 16:29
  Speaker 3: vous comptez sur la chance et la chance n'est pas
• 16:30
  Speaker 3: une stratégie de sécurité. Même avec les processus les plus rigoureux,
• 16:35
  Speaker 3: un obstacle majeur survient au moment de déployer votre solution
• 16:39
  Speaker 3: depuis Power BI Desktop vers Fabric. Jusque-là, la plupart des
• 16:43
  Speaker 3: équipes testent leurs solutions localement sur leur propre machine avec
• 16:46
  Speaker 3: des comptes de tests avec des comptes de tests. Tout
• 16:49
  Speaker 3: semble prévisible, mais dans Fabric, des différences subtilement liées au
• 16:52
  Speaker 3: contexte utilisateur, à la résolution des groupes et au timing
• 16:55
  Speaker 3: d'authentification apparaissent. C'est là que nous rencontrons des imprévus expliquant
• 16:59
  Speaker 3: pourquoi des attributions parfaites en théorie peuvent échouer spectaculairement en production.
• 17:05
  Speaker 3: De desktop vers Fabric, les changements invisibles dans le comportement
• 17:08
  Speaker 3: du RLS Si vous avez déjà cru maîtriser parfaitement la
• 17:12
  Speaker 3: sécurité au niveau des lignes dans Power BI Desktop pour
• 17:14
  Speaker 3: voir tout s'effondrer après publication dans Fabric, vous n'êtes pas seul.
• 17:19
  Speaker 3: C'est ce que les tutoriels RLS omettent souvent, le moment
• 17:22
  Speaker 3: où une logique de rôle et de filtre impeccable se
• 17:24
  Speaker 3: heurtent à la réalité du cloud. Vous avez vérifié chaque filtre,
• 17:29
  Speaker 3: mappé soigneusement chaque groupe et même corrigé ses attributions marginales.
• 17:32
  Speaker 3: Mais dès que vous passez au service Fabric, les choses
• 17:35
  Speaker 3: changent d'une manière qui prend au dépourvu même les administrateurs expérimentés.
• 17:39
  Speaker 3: Commençons par ce que vous voyez dans Desktop. L'aperçu fonctionne
• 17:42
  Speaker 3: exactement comme vous l'attendez. Vous testez les rôles des utilisateurs,
• 17:45
  Speaker 3: vous basculez entre des identités échantillons. Tout s'aligne parfaitement, les
• 17:48
  Speaker 3: chiffres correspondent, et pendant un moment, vous avez l'impression d'avoir
• 17:51
  Speaker 3: maîtrisé un processus simple. Mais dès que vos collaborateurs commencent
• 17:55
  Speaker 3: à ouvrir ce même fichier Power BI dans le cloud,
• 17:57
  Speaker 3: les problèmes commencent à remonter. Quelqu'un signale voir des chiffres
• 18:01
  Speaker 3: en dehors de sa région, ou pire, quelqu'un est bloqué
• 18:03
  Speaker 3: hors d'un jeu de données dont il a absolument besoin
• 18:05
  Speaker 3: pour travailler. Hum. La frustration grandit lorsque vous réalisez que
• 18:08
  Speaker 3: la même configuration RLS qui était étanche sur votre machine
• 18:11
  Speaker 3: agit désormais plus comme une suggestion que comme une règle.
• 18:14
  Speaker 3: Mais cette confusion est due à des différences que vous
• 18:16
  Speaker 3: ne pouvez pas voir avant la publication. L'environnement cloud de
• 18:19
  Speaker 3: Fabric appartient à un monde différent en matière de sécurité,
• 18:22
  Speaker 3: d'identité et de contexte donné. Un piège classique frappe au
• 18:25
  Speaker 3: cœur des modèles RLS dynamiques. Dans Desktop, une fonction DAX
• 18:30
  Speaker 3: comme Carmel Username récupère votre connexion Windows locale. Simple, prévisible
• 18:34
  Speaker 3: et rassurante de stabilité dans votre environnement. Sur Fabric, ce
• 18:38
  Speaker 3: même appel username récupère plutôt votre adresse e-mail complète. Cela
• 18:41
  Speaker 3: semble mineur, mais si votre filtre ou recherche fait référence
• 18:44
  Speaker 3: à des noms de domaine, ou si votre table de
• 18:45
  Speaker 3: sécurité utilise des formats courts au lieu d'e-mail complet, tout
• 18:48
  Speaker 3: le système s'effondre dès que les utilisateurs arrivent sur le cloud. Inévitablement,
• 18:53
  Speaker 3: vous commencez à recevoir des plaintes. Voici ce qui se
• 18:55
  Speaker 3: passe dans des environnements réels. Un rapport montre une répartition
• 18:58
  Speaker 3: par pays dans des stops, mais après publication, les utilisateurs
• 19:02
  Speaker 3: voient des chiffres globaux. Peut-être que votre modèle reposait sur
• 19:04
  Speaker 3: le nom principal de l'utilisateur parce que toutes vos clés
• 19:06
  Speaker 3: d'accès sont des adresses e-mail. C'est une bonne pratique pour
• 19:10
  Speaker 3: le cloud, mais si vous avez commencé dans desktop sans
• 19:11
  Speaker 3: savoir que ce changement se produit, vous déboguez un problème
• 19:14
  Speaker 3: qui n'existe pas localement mais qui explose à grande échelle.
• 19:18
  Speaker 3: La vérité est que ce qui fonctionne sur votre ordinateur
• 19:19
  Speaker 3: portable est plus un prototype décent qu'une solution finie. La
• 19:23
  Speaker 3: logique locale peut dissimuler une mine que seule. L'authentification cloud déclenche.
• 19:28
  Speaker 3: Il existe aussi quelques leviers invisibles que fabrique Actif sans avertissement.
• 19:32
  Speaker 3: Les actualisations de données, par exemple, peuvent se lancer avec
• 19:33
  Speaker 3: des identifiants différents ou aboutir chez un propriétaire de modèles
• 19:36
  Speaker 3: différents de celui prévu. Si le propriétaire du jeu de
• 19:39
  Speaker 3: données publié n'est pas dans le bon groupe, il peut
• 19:41
  Speaker 3: finir par ne voir aucune donnée ou accéder à tout
• 19:43
  Speaker 3: par accident. Changer de propriétaire dans le cloud n'affecte pas
• 19:47
  Speaker 3: seulement les permissions. Cela peut rompre les connexions au passant.
• 19:50
  Speaker 3: ou modifier la façon dont les identifiants sont évalués par
• 19:52
  Speaker 3: rapport au système source. Parfois, les paramètres du locataire cachent
• 19:56
  Speaker 3: des comportements hérités ou des options par défaut qui remplacent
• 19:58
  Speaker 3: ce que vous avez configuré lors des tests dans desktop.
• 20:02
  Speaker 3: Pour les organisations ayant des politiques de tenant stratifiées, un
• 20:05
  Speaker 3: simple changement comme l'activation du partage externe peut bouleverser du
• 20:07
  Speaker 3: jour au lendemain la logique d'accès. Ce qui déroute, c'est
• 20:10
  Speaker 3: la subtilité de ces changements. Ils ne vous crient pas« Eh,
• 20:13
  Speaker 3: votre RLS est cassé!» Au lieu de cela, les choses
• 20:16
  Speaker 3: fonctionnent silencieusement de travers. Une petite modification de l'authentification ou
• 20:20
  Speaker 3: de la résolution des groupes lors de la connexion transforme
• 20:22
  Speaker 3: totalement le contexte de sécurité. Les forums de support Microsoft
• 20:26
  Speaker 3: regorgent d'administrateurs racontant des rapports ayant réussi tous les tests
• 20:30
  Speaker 3: locaux pour ensuite échouer une fois déployés dans le cloud. Loud!
• 20:37
  Speaker 3: On voit des fils de discussion où, après un déploiement,
• 20:39
  Speaker 3: les équipes tentent désespérément de corriger leur rôle RLS non
• 20:43
  Speaker 3: par mauvaise logique, mais parce que le passage à fabrique
• 20:46
  Speaker 3: a modifié le contexte d'identité. Même les mises à jour
• 20:52
  Speaker 3: cloud ou globales peuvent orienter la sécurité dans de nouvelles directions. Parfois,
• 20:57
  Speaker 3: après une mise à jour, les mappages de groupe gérés
• 20:59
  Speaker 3: par Azure AD se synchronisent différemment. donnant la priorité à
• 21:03
  Speaker 3: des attributions fantômes ou causant des erreurs sur des recherches dynamiques.
• 21:08
  Speaker 3: Mais petits changements s'accumulent. Un ajustement dans une partie de
• 21:11
  Speaker 3: la pile se répercute sur tout le maillage de sécurité,
• 21:13
  Speaker 3: rendant obsolètes les modèles pourtant fiables du trimestre dernier. C'est
• 21:18
  Speaker 3: pourquoi les équipes terrain traitent désormais les tests RLS comme
• 21:20
  Speaker 3: une tâche de production et non comme un simple contrôle local. Ah,
• 21:23
  Speaker 3: il ne suffit pas de cliquer sur les rôles depuis
• 21:25
  Speaker 3: votre propre ordinateur? Vous devez déployer le modèle dans Fabric,
• 21:29
  Speaker 3: utiliser de vrais comptes utilisateurs et tester le flux complet
• 21:33
  Speaker 3: des permissions. C'est seulement ainsi que vous détecterez les bugs
• 21:37
  Speaker 3: d'authentification ou les décalages entre les groupes Azure AD et
• 21:41
  Speaker 3: la vision de Power ADI. Certaines organisations scriptent même des
• 21:45
  Speaker 3: audits RLS périodiques dans le cloud pour vérifier les écarts
• 21:48
  Speaker 3: entre la logique du modèle et ce que Fabric applique réellement.
• 21:53
  Speaker 3: Il n'y a pas de raccourci ici. Si vous ne
• 21:55
  Speaker 3: testez pas avec de vraies personnes dans l'environnement réel, votre
• 21:58
  Speaker 3: RLS repose essentiellement sur l'espoir. Le cloud est l'arbitre ultime
• 22:04
  Speaker 3: et le seul moyen de voir comment les filtres zéro
• 22:06
  Speaker 3: l'interagissent est de concevoir votre RLS pour la production dès
• 22:10
  Speaker 3: le départ. Si vous repoussez ces tests, vous pilotez à
• 22:15
  Speaker 3: l'aveugle et les conséquences données exposées, équipes frustrées, sécurité, compromises
• 22:19
  Speaker 3: coûteront bien plus cher à corriger une fois le rapport
• 22:22
  Speaker 3: en service terminé. Face à ce contexte, la question n'est
• 22:27
  Speaker 3: pas simplement de corriger votre RLS à chaque changement. Il
• 22:31
  Speaker 3: s'agit de savoir si vous avez un plan viable à
• 22:32
  Speaker 3: mesure que votre configuration fabrique se complexifie, que vos données
• 22:35
  Speaker 3: croissent et que le modèle métier évolue.