Planification de l’implémentation de Power BI : audit au niveau du locataire

Notes

Cet article fait partie de la série d’articles sur la planification de l’implémentation de Power BI. Cette série se concentre principalement sur la charge de travail Power BI au sein de Microsoft Fabric. Pour une introduction à la série, consultez Planification de l’implémentation de Power BI.

Cet article sur la planification de l’audit au niveau du locataire est principalement consacré aux points suivants :

• Administrateurs Power BI : Les administrateurs chargés de superviser Power BI dans l’organisation. Les administrateurs Power BI peuvent avoir besoin de collaborer avec les équipes informatique, de la sécurité, de l’audit interne et d’autres équipes pertinentes.
• Centre d’excellence, service informatique et équipe BI : les équipes qui sont également responsables de la supervision de Power BI. Ils peuvent avoir besoin de collaborer avec les administrateurs Power BI et d’autres équipes pertinentes.

Important

Nous vous recommandons de suivre de près le plan de publication de Power BI pour en savoir plus sur les améliorations futures des fonctionnalités d’audit et de monitoring.

L’objectif d’une solution d’audit au niveau du locataire est de capturer et d’analyser des données pour tous les utilisateurs, activités et solutions déployés sur un locataire Power BI. Ces données d’audit au niveau du locataire sont précieuses pour divers usages, par exemple, pour analyser les efforts d’adoption, comprendre les modèles d’utilisation, éduquer les utilisateurs, prendre en charge les utilisateurs, atténuer les risques, améliorer la conformité, gérer les coûts de licence et monitorer les performances.

La création d’une solution d’audit de bout en bout sécurisée et prête pour la production est un projet important qui prend du temps. Voyez cela comme la création de business intelligence sur la business intelligence (BI sur BI). Pour comprendre pourquoi les données d’audit sont si précieuses, consultez Vue d’ensemble de l’audit et du monitoring.

Pour un audit au niveau du rapport, qui s’adresse aux créateurs de rapports, consultez Audit au niveau du rapport.

Pour l’audit des ressources de données, qui s’adresse aux créateurs de données, consultez Audit au niveau des données.

Le reste de cet article est consacré à l’audit au niveau du locataire.

Conseil

L’objectif principal de cet article est de vous aider à planifier la création d’une solution d’audit de bout en bout. Le contenu de cet article est organisé en quatre phases et vous avez besoin des informations de plusieurs phases. Par exemple, la phase 1 donne des informations sur la planification de l’utilisation d’un principal de service et la phase 2, des informations sur les prérequis et la configuration.

Par conséquent, nous vous recommandons de lire d’abord l’intégralité de cet article pour vous familiariser avec les implications. Vous serez ensuite bien préparé pour planifier et créer votre solution d’audit de manière itérative.

Quand vous planifiez la création d’une solution d’audit au niveau du locataire, prévoyez du temps pour les quatre phases suivantes.

• Phase 1 : Planification et décisions
  • Exigences et priorités
  • Données nécessaires
  • Type de solution d’audit
  • Autorisations et responsabilités
  • Décisions techniques
  • Décisions relatives à la source de données
• Phase 2 : Prérequis et configuration
  • Créer un compte de stockage
  • Installer les logiciels et configurer les services
  • Inscrire une application Microsoft Entra
  • Définir les paramètres du locataire Power BI
• Phase 3 : Développement de la solution et analytique
  • Extraire et stocker les données brutes
  • Créer les données organisées
  • Créer un modèle de données
  • améliorer le modèle de données
  • Créer des rapports analytiques
  • Effectuer des actions en fonction des données
• Phase 4 : Maintenir, améliorer et monitorer
  • Opérationnaliser et améliorer
  • Documentation et support
  • Activer les alertes
  • Gestion continue

Phase 1 : Planification et décisions

La première phase se concentre sur la planification et la prise de décision. Comme il y a de nombreuses exigences et priorités à prendre en compte, nous vous recommandons de prendre suffisamment de temps pour comprendre les rubriques présentées dans cette section. L’objectif est de prendre les bonnes décisions à l’avance pour que les phases en aval se déroulent sans problème.

Exigences et priorités

Dans la phase initiale, l’objectif est d’identifier ce qui est le plus important. Concentrez-vous sur ce qui compte le plus et comment mesurer l’impact dans votre organisation. Essayez de définir des exigences orientées métier plutôt que des exigences orientées technologie.

Voici quelques questions auxquelles vous devez répondre.

• Quelles sont les questions clés auxquelles vous devez répondre ? Le volume des données d’audit à explorer est immense. La façon la plus efficace d’aborder l’audit est de répondre à des questions spécifiques.
• Quels sont vos objectifs en matière d’adoption et de culture des données ? Par exemple, vous avez peut-être pour objectif d’augmenter le nombre de créateurs de contenu BI en libre-service dans l’organisation. Dans ce cas, vous devez mesurer les activités utilisateur liées à la création, la modification et la publication de contenu.
• Quels sont les risques immédiats ? Par exemple, vous avez peut-être déjà été confronté au partage excessif du contenu par le passé. La formation des utilisateurs a été améliorée depuis, et vous voulez maintenant auditer les paramètres de sécurité et les activités de manière continue.
• Existe-t-il actuellement des indicateurs de performance clés (KPI) ou des objectifs organisationnels ? Par exemple, vous pouvez avoir un KPI organisationnel pour la transformation numérique ou pour axer davantage l’organisation sur les données. Les données d’audit au niveau du locataire peuvent vous aider à déterminer si votre implémentation de Power BI est alignée sur ces objectifs.

Conseil

Vérifiez les exigences d’audit et définissez des priorités avec votre cadre responsable et votre centre d’excellence. Vous pouvez être tenté d’extraire les données d’audit et de commencer à créer des rapports basés sur un grand nombre de données intéressantes. Toutefois, il est peu probable que vous tiriez une grande valeur de votre solution d’audit si elle n’est pas cadrée par les questions auxquelles vous devez répondre et les actions que vous envisagez d’entreprendre.

Pour plus d’idées sur l’utilisation des données d’audit, consultez Vue d’ensemble de l’audit et du monitoring.

Check-list : voici les décisions et actions clés à prendre en compte pour identifier les exigences et les priorités :

• Identifier les exigences : collectez et documentez les principales exigences métier pour l’audit de votre locataire Power BI.
• Hiérarchiser les exigences : définissez des priorités pour les exigences, en les classant en priorités immédiates, à court terme, à moyen terme et à long terme (backlog).
• Créer un plan pour les priorités immédiates : mettez en place un plan pour commencer à collecter des données afin qu’elles soient disponibles quand vous en avez besoin.
• Réévaluer régulièrement les exigences : créez un plan pour réévaluer les exigences régulièrement (par exemple, deux fois par an). Vérifiez si la solution d’audit et de monitoring répond aux exigences indiquées. Mettez à jour les éléments d’action de votre plan selon les besoins.

Données nécessaires

Une fois que vous avez défini les exigences et les priorités (décrites précédemment), vous êtes prêt à identifier les données dont vous avez besoin. Quatre catégories de données sont décrites dans cette section.

• Données d’activité utilisateur
• Inventaire du locataire
• Données d’utilisateurs et de groupes
• Données de sécurité

La plupart des données dont vous avez besoin sont fournies par les API d’administration, qui apportent une multitude de métadonnées concernant le locataire Power BI. Pour plus d’informations, consultez Choisir une API utilisateur ou une API d’administration plus loin dans cet article.

Données d’activité utilisateur

Les données sur les activités des utilisateurs doivent être votre première priorité. Les activités utilisateur, également appelées événements ou opérations, sont utiles à des fins très diverses.

Le plus souvent, ces données sont désignées comme le journal d’activité ou le journal des événements. Techniquement, il y a plusieurs façons d’acquérir des données d’activité utilisateur (le journal d’activité étant l’une des méthodes). Pour plus d’informations sur les décisions et les activités impliquées, consultez Accéder aux données d’activité utilisateur plus loin dans cet article.

Voici quelques questions courantes auxquelles les données d’activité utilisateur peuvent répondre.

• Identifier les principaux utilisateurs et le contenu principal
  • Quel contenu est consulté le plus souvent et par quels utilisateurs ?
  • Quelles sont les tendances quotidiennes, hebdomadaires et mensuelles de consultation du contenu ?
  • La tendance des vues des rapports est-elle à la hausse ou à la baisse ?
  • Combien y a-t-il d’utilisateurs actifs ?
• Comprendre le comportement de l’utilisateur
  • Quel type de sécurité est utilisé le plus souvent (applications, espaces de travail ou partage par élément) ?
  • Les utilisateurs utilisent-ils le plus souvent des navigateurs ou des applications mobiles ?
  • Qui sont les créateurs de contenu qui publient et mettent à jour le contenu de manière la plus active ?
  • Quel contenu est publié ou mis à jour, quand et par quels utilisateurs ?
• Identifier les opportunités de formation et d’éducation des utilisateurs
  • Qui partage (trop) de données à partir de son espace de travail personnel ?
  • Qui fait un grand nombre d’exportations ?
  • Qui télécharge régulièrement du contenu ?
  • Qui publie de nombreux nouveaux modèles sémantiques, précédemment appelés jeux de données ?
  • Qui utilise beaucoup les abonnements ?
• Améliorer les efforts de gouvernance et de conformité
  • Quand les paramètres du locataire sont-ils changés et par quel administrateur Power BI ?
  • Qui a démarré un essai Power BI ?
  • Quel contenu est consulté par les utilisateurs externes, qui, quand et comment ?
  • Qui a ajouté ou mis à jour une étiquette de confidentialité ?
  • Quel est le pourcentage de vues de rapport basées sur des modèles sémantiques certifiés ?
  • Quel est le pourcentage de modèles sémantiques qui prennent en charge plusieurs rapports ?
  • Quand une passerelle ou une source de données est-elle créée ou mise à jour, et par quel utilisateur ?

Pour plus d’informations sur l’utilisation de ces données, consultez Comprendre les modèles d’utilisation.

Important

Si vous n’avez pas déjà commencé à extraire et stocker les données d’activité utilisateur, faites-en une priorité urgente. Au minimum, veillez à extraire les données brutes et à les stocker dans un emplacement sécurisé. De cette façon, les données sont disponibles quand vous êtes prêt à les analyser. L’historique est disponible pendant 30 jours ou 90 jours, selon la source que vous utilisez.

Pour plus d’informations, consultez la section Accéder aux données d’activité utilisateur plus loin dans cet article.

Inventaire du locataire

Souvent, la deuxième priorité est de récupérer les données pour créer un inventaire de locataire. On parle parfois d’inventaire d’espace de travail, de métadonnées d’espace de travail ou de métadonnées de locataire.

Un inventaire de locataire est un instantané à un moment donné. Il décrit ce qui est publié dans le locataire. L’inventaire du locataire ne comprend ni les données réelles ni les rapports réels. À la place, ce sont des métadonnées qui décrivent tous les espaces de travail et leurs éléments (comme les modèles sémantiques et les rapports).

Voici quelques questions courantes auxquelles l’inventaire du locataire peut répondre.

• Comprendre la quantité de contenu que vous avez et où
  • Quels espaces de travail ont le plus de contenu ?
  • Quel type de contenu est publié dans chaque espace de travail (en particulier quand vous séparez les espaces de travail de création de rapports et les espaces de travail de données) ?
  • Quelles dépendances existent entre les éléments (comme les flux de données qui prennent en charge de nombreux modèles sémantiques ou un modèle sémantique qui sert de source pour d’autres modèles composites) ?
  • Quelle est la traçabilité des données (dépendances entre éléments Power BI, y compris sources de données externes) ?
  • Y a-t-il des rapports orphelins (déconnectés de leur modèle sémantique) ?
• Comprendre le taux de modèles sémantiques aux rapports
  • Quel est le taux de réutilisation du modèle sémantique ?
  • Y a-t-il des modèles sémantiques dupliqués ou très similaires ?
  • Y a-t-il des possibilités de regrouper des modèles sémantiques ?
• Comprendre les tendances entre points dans le temps
  • Le nombre de rapports augmente-t-il au fil du temps ?
  • Le nombre de modèles sémantiques augmente-t-il au fil du temps ?
• Identifier le contenu inutilisé
  • Quels sont les rapports inutilisés (ou sous-utilisés) ?
  • Quels modèles sémantiques ne sont pas utilisés (ou sous-utilisés) ?
  • Y a-t-il du contenu pouvant être retiré ?

Un inventaire de locataire vous permet d’utiliser les noms actuels dans l’analyse des activités historiques. L’instantané des éléments de votre locataire contient les noms de tous les éléments à cet instant. Les noms d’éléments actuels sont utiles pour les rapports historiques. Par exemple, si un rapport a été renommé il y a trois mois, le journal d’activité à cet instant enregistre le nom de l’ancien rapport. Avec un modèle de données correctement défini, vous pouvez utiliser le dernier inventaire de locataire pour localiser un élément à partir de son nom actuel (au lieu de son ancien nom). Pour plus d'informations, consultez Créer un modèle de données plus loin dans cet article.

Pour plus d’informations sur l’utilisation d’un inventaire de locataire, consultez Comprendre le contenu publié.

Conseil

Vous utilisez souvent les événements d’activité utilisateur (décrits dans la section précédente) et l’inventaire de locataire pour avoir une image complète. De cette façon, vous améliorez la valeur de toutes les données.

Comme un inventaire de locataire est un instantané à un moment donné, vous devez choisir une fréquence d’extraction et de stockage des métadonnées. Un instantané hebdomadaire est utile pour faire des comparaisons entre deux points dans le temps. Par exemple, si vous voulez investiguer les paramètres de sécurité d’un espace de travail, vous avez besoin de l’instantané précédent de l’inventaire de locataire, des événements du journal d’activité et de l’instantané actuel de l’inventaire de locataire.

Il y a deux grandes façons de créer un inventaire de locataire. Pour plus d’informations sur les décisions et les activités impliquées, consultez Accéder aux données de l’inventaire de locataire plus loin dans cet article.

Données d’utilisateurs et de groupes

Avec l’augmentation de vos besoins analytiques, vous allez probablement vouloir ajouter des données sur les utilisateurs et les groupes dans votre solution d’audit de bout en bout. Pour récupérer ces données, vous pouvez utiliser Microsoft Graph, qui est la source officielle pour obtenir des informations sur les utilisateurs et les groupes Microsoft Entra ID (anciennement Azure Active Directory).

Les données récupérées à partir des API REST Power BI comprennent une adresse e-mail pour décrire l’utilisateur, ou le nom d’un groupe de sécurité. Ces données sont un instantané à un moment donné.

Voici quelques questions courantes auxquelles Microsoft Graph peut répondre.

• Identifier les utilisateurs et les groupes
  • Quel est le nom d’utilisateur complet (en plus de l’adresse e-mail), le service ou la localisation indiqués dans le profil utilisateur ?
  • Qui sont les membres d’un groupe de sécurité ?
  • Qui est le propriétaire d’un groupe de sécurité (pour gérer les membres) ?
• Obtenir des informations supplémentaires sur l’utilisateur
  • Quelles sont les licences (Power BI Pro ou Power BI Premium par utilisateur (PPU)) qui sont attribuées aux utilisateurs ?
  • Quels sont les utilisateurs qui se connectent le plus souvent ?
  • Quels sont les utilisateurs qui ne se sont pas connectés récemment au service Power BI ?

Avertissement

Certaines méthodes plus anciennes (qui sont largement documentées en ligne) permettant d’accéder aux données des utilisateurs et des groupes sont dépréciées et vous ne devez pas les utiliser. Dans la mesure du possible, utilisez Microsoft Graph comme source officielle des données d’utilisateurs et de groupes.

Pour plus d’informations et pour avoir des recommandations sur l’accès aux données à partir de Microsoft Graph, consultez Accéder aux données d’utilisateurs et de groupes plus loin dans cet article.

Données de sécurité

Vous devrez peut-être effectuer des audits de sécurité réguliers.

Voici quelques questions courantes auxquelles les API REST Power BI peuvent répondre.

• Identifier les personnes et les applications
  • Quels sont les rapports auxquels un utilisateur, un groupe ou un principal de service a accès ?
  • Quels sont les utilisateurs, groupes ou principaux de service qui sont abonnés à des rapports avec un abonnement aux e-mails ?
• Comprendre les autorisations de contenu
  • Quels rôles d’espace de travail sont attribués à quels utilisateurs et groupes ?
  • Quels sont les utilisateurs et groupes qui sont attribués à chaque audience d’application Power BI ?
  • Quelles sont les autorisations par élément qui sont attribuées, pour quels rapports et pour quels utilisateurs ?
  • Quelles sont les autorisations par élément qui sont attribuées, pour quels modèles sémantiques et pour quels utilisateurs ?
  • Quels sont les modèles sémantiques et datamarts qui ont une sécurité au niveau des lignes (SNL) définie ?
  • Quels sont les éléments partagés avec des personnes dans l’ensemble de l’organisation ?
  • Quels sont les éléments publiés publiquement sur Internet ?
• Comprendre les autres autorisations
  • Qui est autorisé à publier en utilisant un pipeline de déploiement ?
  • Qui est autorisé à gérer les passerelles et les connexions de données ?
  • Qui est autorisé à gérer une capacité Premium ?

Important

Cet article fait parfois référence à Power BI Premium ou à ses abonnements de capacité (SKU P). Sachez que Microsoft regroupe actuellement des options d’achat et met hors service les SKU Power BI Premium par capacité. Les clients nouveaux et existants doivent plutôt envisager l’achat d’abonnements de capacité Fabric (SKU F).

Pour plus d’informations, consultez Importante mise à jour à venir des licences Power BI Premium et FAQ sur Power BI Premium.

Conseil

Pour plus d’informations sur la sécurité, consultez les articles sur la planification de la sécurité.

Cette liste de questions courantes n’est pas exhaustive, il existe une grande variété d’API REST Power BI disponibles. Pour plus d’informations, consultez Utilisation des API REST Power BI.

Pour plus d’informations sur l’utilisation des API d’administration par rapport aux API utilisateur (y compris comment cela affecte les autorisations nécessaires pour l’utilisateur qui extrait les données), consultez Choisir une API utilisateur ou une API d’administration plus loin dans cet article.

Check-list : voici les décisions et actions clés à prendre en compte pour identifier les données nécessaires à l’audit :

• Identifier les besoins spécifiques concernant les données d’activité utilisateur : validez les exigences que vous avez collectées. Identifiez les données d’audit dont vous avez besoin pour répondre à chaque exigence de données d’activité utilisateur.
• Identifier les besoins spécifiques concernant les données d’inventaire de locataire : validez les exigences que vous avez collectées. Identifiez les données d’audit dont vous avez besoin pour compiler un inventaire de locataire.
• Identifier les besoins spécifiques concernant les données d’utilisateurs et de groupes : validez les exigences que vous avez collectées. Identifiez les données d’audit dont vous avez besoin pour répondre à chaque exigence de données d’utilisateurs et de groupes.
• Identifier les besoins spécifiques concernant les données de sécurité : validez les exigences que vous avez collectées. Identifiez les données d’audit dont vous avez besoin pour répondre à chaque exigence de données de sécurité.
• Vérifier les priorités : vérifiez l’ordre des priorités pour savoir ce que vous devez développer en premier.
• Choisir la fréquence de capture des activités : déterminez la fréquence à laquelle capturer les événements d’activité (par exemple, une fois par jour).
• Choisir la fréquence de capture des instantanés : déterminez l’intervalle de capture des données d’instantané, comme l’inventaire de locataire, ou les données d’utilisateurs et de groupes.

Type de solution d’audit

L’audit au niveau du locataire est effectué manuellement ou par des processus automatisés.

La plupart des nouveaux processus d’audit commencent avec un processus manuel, en particulier pendant le développement et les tests. Un processus d’audit manuel peut évoluer pour devenir un processus automatisé. Toutefois, les processus d’audit ne doivent pas tous être entièrement automatisés.

Processus d’audit manuels

L’audit manuel utilise des scripts et des processus qui sont exécutés à la demande par un utilisateur (généralement un administrateur Power BI). Si nécessaire, l’utilisateur exécute des requêtes de manière interactive pour récupérer des données d’audit.

L’audit manuel est adapté pour :

• Les nouveaux scripts qui sont développés et testés.
• Les besoins occasionnels d’audit ponctuels.
• Les besoins d’audit exploratoire.
• Les processus d’audit non essentiels qui n’ont pas besoin d’une prise en charge complète.

Processus d’audit automatisés

Les données d’audit dont vous avez besoin de manière récurrente doivent être automatisées. Elles sont extraites et traitées selon une planification régulière, ce qu’on appelle un processus automatisé. On parle parfois de processus sans assistance.

Les objectifs d’un processus automatisé sont de réduire l’effort manuel, réduire le risque d’erreur, augmenter la cohérence et éviter de dépendre d’un utilisateur pour lancer l’exécution.

L’audit automatisé est adapté pour :

• Les processus d’audit qui s’exécutent en production.
• Les processus sans assistance qui s’exécutent selon une planification régulière.
• Les scripts qui ont été entièrement testés.
• Les processus d’audit essentiels qui constituent une source de données pour d’autres rapports (ou d’autres processus).
• Les processus d’audit qui sont documentés et pris en charge.

Le type de processus (manuel ou automatisé) peut avoir un impact sur la façon dont vous gérez l’authentification. Par exemple, un administrateur Power BI peut utiliser l’authentification utilisateur pour un processus d’audit manuel, et un principal de service pour un processus automatisé. Pour plus d’informations, consultez Déterminer la méthode d’authentification plus loin dans cet article.

Conseil

S’il y a un besoin régulier et récurrent de données d’audit qui sont actuellement gérées manuellement, investissez du temps pour les automatiser. Par exemple, si un administrateur Power BI exécute manuellement un script chaque jour pour récupérer des données à partir du journal d’activité Power BI, vous risquez de manquer des données si cette personne est malade ou en vacances.

Check-list : voici les décisions et actions clés à prendre en compte pour choisir le type de solution d’audit à développer :

• Déterminer l’objectif principal de chaque nouvelle exigence d’audit : choisissez s’il faut utiliser un processus manuel ou automatisé pour chaque nouvelle exigence. Déterminez si cette décision est temporaire ou permanente.
• Créer un plan pour mettre en place l’automatisation : quand cela est approprié pour une exigence d’audit particulière, créez un plan pour l’automatiser, quand et par qui.

Autorisations et responsabilités

À ce stade, vous devez avoir une idée claire de ce que vous souhaitez faire et des données dont vous avez initialement besoin. Le moment est venu de prendre des décisions concernant les autorisations des utilisateurs, ainsi que les rôles et les responsabilités.

Autorisations utilisateur

Quand vous planifiez la création d’une solution d’audit de bout en bout, réfléchissez aux autorisations à accorder aux autres utilisateurs qui ont besoin d’accéder aux données. Plus précisément, choisissez qui est autorisé à accéder aux données d’audit et à les consulter.

Voici quelques points à prendre en compte.

Accès direct aux données d’audit

Vous devez choisir qui peut accéder directement aux données d’audit. Il y a plusieurs façons de procéder.

• Qui doit être administrateur Power BI ? Un administrateur Power BI a accès à toutes les métadonnées de locataire, y compris les API d’administration. Pour plus d’informations sur le choix de l’administrateur Power BI, consultez Planification de la sécurité au niveau du locataire.
• Qui peut utiliser un principal de service existant ? Pour utiliser un principal de service (au lieu d’autorisations utilisateur) afin d’accéder aux données d’audit, les utilisateurs autorisés doivent recevoir un secret pour pouvoir effectuer l’authentification basée sur un mot de passe. L’accès aux secrets (et aux clés) doit être très étroitement contrôlé.
• L’accès doit-il être étroitement contrôlé ? Certains secteurs d’activité qui ont des exigences réglementaires et de conformité doivent contrôler l’accès plus étroitement que d’autres.
• Y a-t-il de grands volumes de données d’activité ? Pour éviter d’atteindre les limitations des API, vous devrez peut-être contrôler étroitement qui est autorisé à accéder directement aux API qui produisent des données d’audit. Dans ce cas, vérifiez qu’il n’y a pas de double emploi ou de chevauchement des efforts.

Accès aux données brutes extraites

Vous devez choisir qui peut consulter les données brutes extraites et écrites dans un emplacement de stockage. Le plus souvent, l’accès aux données brutes est limité aux administrateurs et aux auditeurs. Le centre d’excellence peut également nécessiter un accès. Pour plus d’informations, consultez Déterminer où stocker les données d’audit plus loin dans cet article.

Accès aux données analytiques organisées

Vous devez choisir qui peut consulter les données organisées et transformées prêtes pour l’analytique. Ces données doivent toujours être mises à la disposition des administrateurs et des auditeurs. Parfois, un modèle de données est mis à la disposition d’autres utilisateurs dans l’organisation, en particulier quand vous créez un modèle sémantique Power BI avec une sécurité au niveau des lignes. Pour plus d’informations, consultez Planifier la création de données organisées plus loin dans cet article.

Rôles et responsabilités

Une fois que vous avez choisi le fonctionnement des autorisations utilisateur, vous pouvez commencer à réfléchir aux rôles et aux responsabilités. Nous vous recommandons d’impliquer les bonnes personnes dès le début, en particulier quand il y a plusieurs développeurs ou équipes impliqués dans la création de la solution d’audit de bout en bout.

Choisissez les utilisateurs ou l’équipe qui sont responsables des activités suivantes.

Rôle	Types de responsabilité	Rôle généralement effectué par
Communiquer avec les parties prenantes	Activités de communication et collecte des exigences.	Centre d’excellence en partenariat avec le service informatique. Peut également comprendre certaines personnes des unités commerciales clés.
Déterminer les priorités et fournir une orientation sur les exigences	Activités de prise de décision liées à la solution d’audit de bout en bout, y compris comment répondre aux exigences.	L’équipe qui supervise Power BI dans l’organisation, comme le centre d’excellence. Le cadre responsable ou un comité directeur de gouvernance des données pourrait s’impliquer pour prendre des décisions critiques ou faire remonter les problèmes.
Extraire et stocker les données brutes	Création de scripts et de processus pour accéder aux données et les extraire. Implique également l’écriture des données brutes dans le stockage.	Personnel d’engineering données, généralement dans le service informatique et en partenariat avec le centre d’excellence.
Créer les données organisées	Nettoyage des données, transformation et création des données organisées dans une conception de schéma en étoile.	Personnel d’engineering données, généralement dans le service informatique et en partenariat avec le centre d’excellence.
Créer un modèle de données	Création d’un modèle de données analytique, basé sur les données organisées.	Créateur(s) de contenu Power BI, généralement dans le service informatique ou le centre d’excellence.
Créer des rapports analytiques	Création de rapports pour analyser les données organisées. Changements continus des rapports en fonction des nouvelles exigences et quand de nouvelles données d’audit sont disponibles.	Créateur(s) de rapports Power BI, généralement dans le service informatique ou le centre d’excellence.
Analyser les données et agir en fonction des résultats	Analyser les données et agir en réponse aux données d’audit.	L’équipe qui supervise Power BI dans l’organisation, généralement le centre d’excellence. Peut également comprendre d’autres équipes en fonction des résultats d’audit et de l’action. Les autres équipes peuvent être chargées de la sécurité, de la conformité, du juridique, de la gestion des risques ou de la gestion des changements.
Test et validation	Faire des tests pour vérifier que les exigences d’audit sont remplies et que les données présentées sont exactes.	Créateur(s) de contenu Power BI, en partenariat avec l’équipe qui supervise Power BI dans l’organisation.
Sécuriser les données	Définir et gérer la sécurité de chaque couche de stockage, y compris les données brutes et les données organisées. Gérer l’accès aux modèles sémantiques créés pour l’analyse des données.	Administrateur du système qui stocke les données, en partenariat avec l’équipe qui supervise Power BI dans l’organisation.
Planification et automatisation	Opérationnaliser une solution et planifier le processus avec l’outil choisi.	Personnel d’engineering données, généralement dans le service informatique et en partenariat avec le centre d’excellence.
Assurer le support de la solution	Monitorer la solution d’audit, y compris l’exécution des travaux, les erreurs et la prise en charge des problèmes techniques.	L’équipe qui gère le support du système Power BI, qui est généralement le service informatique ou le centre d’excellence.

La plupart des rôles et responsabilités ci-dessus peuvent être regroupés s’ils sont exécutés par la même équipe ou la même personne. Par exemple, vos administrateurs Power BI peuvent effectuer certains de ces rôles.

Il est également possible que différentes personnes jouent des rôles différents, selon les circonstances. Les actions sont contextuelles en fonction des données d’audit et de l’action proposée.

Prenons plusieurs exemples.

• Exemple 1 : les données d’audit montrent que certains utilisateurs exportent fréquemment des données vers Excel. Action effectuée : le centre d’excellence contacte les utilisateurs spécifiques pour comprendre leurs besoins et leur apprendre de meilleures alternatives.
• Exemple 2 : les données d’audit montrent que l’accès des utilisateurs externes se produit de manière inattendue. Actions effectuées : un administrateur système du service informatique met à jour les paramètres Microsoft Entra ID appropriés pour l’accès des utilisateurs externes. L’administrateur Power BI met à jour le paramètre de locataire lié à l’accès des utilisateurs externes. Le centre d’excellence met à jour la documentation et la formation pour les créateurs de contenu qui gèrent la sécurité. Pour plus d’informations, consultez Stratégie pour les utilisateurs externes.
• Exemple 3 : les données d’audit montrent que plusieurs modèles de données définissent la même mesure différemment (disponible à partir des API d’analyse des métadonnées, si les paramètres de locataire des métadonnées détaillées l’autorisent). Action effectuée : le comité de gouvernance des données démarre un projet pour définir des définitions communes. Le centre d’excellence met à jour la documentation et la formation pour les créateurs de contenu qui créent des modèles de données. Le centre d’excellence travaille également avec les créateurs de contenu pour mettre à jour leurs modèles, selon les besoins. Pour plus d’informations sur la récupération des métadonnées détaillées, consultez Accéder aux données d’inventaire de locataire plus loin dans cet article.

Notes

La configuration des processus d’extraction de données est généralement un effort ponctuel avec des améliorations et des dépannages occasionnels. L’analyse des données et les actions en réponse à ces données nécessitent un effort continu et régulier.

Check-list : voici les décisions et actions clés à prendre en compte pour choisir les autorisations et les responsabilités :

• Identifier les équipes impliquées : déterminez les équipes qui sont impliquées dans la création et la prise en charge de bout en bout de la solution d’audit.
• Choisir des autorisations utilisateur : déterminez comment les autorisations utilisateur sont configurées pour accéder aux données d’audit. Créez une documentation des décisions clés pour référence ultérieure.
• Choisir les rôles et les responsabilités : vérifiez que les attentes sont claires concernant qui fait quoi, en particulier quand plusieurs équipes sont impliquées. Créez une documentation pour les rôles et les responsabilités, qui comprend les actions attendues.
• Attribuer des rôles et des responsabilités : attribuez des rôles et des responsabilités spécifiques à des personnes ou des équipes spécifiques. Mettez à jour les descriptions de travail individuelles avec les Ressources humaines, selon les besoins.
• Créer un plan de formation : établissez un plan de formation du personnel quand de nouvelles compétences sont nécessaires.
• Créer un plan de formation croisée : vérifiez qu’une formation croisée et des remplaçants sont en place pour les rôles clés.

Décisions techniques

Quand vous planifiez une solution d’audit au niveau du locataire, vous devez prendre des décisions techniques importantes. Pour améliorer la cohérence, éviter les remaniements et améliorer la sécurité, nous vous recommandons de prendre ces décisions le plus tôt possible.

La première phase de planification consiste à prendre les décisions suivantes.

• Sélectionner une technologie pour accéder aux données d’audit
• Déterminer la méthode d’authentification
• Choisir une API utilisateur ou une API d’administration
• Choisir des API ou des applets de commande PowerShell
• Déterminer où stocker les données d’audit
• Planifier la création de données organisées

Sélectionner une technologie pour accéder aux données d’audit

La première chose à faire est de choisir comment accéder aux données d’audit.

Le moyen le plus simple de commencer consiste à utiliser les rapports prédéfinis disponibles dans l’espace de travail de surveillance administrateur.

Lorsque vous avez besoin d’accéder directement aux données et de créer votre propre solution, vous utilisez une interface de programme d’application (API, Application Programming Interface). Les API sont conçues pour échanger des données sur Internet. Les API REST Power BI prennent en charge les demandes de données avec le protocole HTTP. N’importe quel langage ou outil peut appeler des API REST Power BI s’il est capable d’envoyer une requête HTTP et de recevoir une réponse JSON.

Conseil

Les applets de commande PowerShell utilisent les API REST Power BI pour accéder aux données d’audit. Pour plus d’informations, consultez Choisir des API ou des applets de commande PowerShell plus loin dans cet article.

Cette section se concentre sur votre choix de technologie. Pour plus d’informations sur la source permettant d’accéder à des types spécifiques de données d’audit, consultez Choix des sources de données plus loin dans cet article.

Options de plateforme

Il y a de nombreuses façons d’accéder aux données d’audit. Selon la technologie que vous choisissez, vous pouvez pencher pour un langage plutôt qu’un autre. Vous devez peut-être également prendre une décision spécifique sur la planification de l’exécution de vos scripts. Les technologies diffèrent considérablement dans leur courbe d’apprentissage et leur facilité de prise en main.

Voici quelques technologies que vous pouvez utiliser pour récupérer des données en utilisant les API REST Power BI.

Technology	Bon choix pour les processus d’audit manuels	Bon choix pour les processus d’audit automatisés
Espace de travail de supervision de l’administration
Try-it
PowerShell
Power BI Desktop
Power Automate
Service Azure préféré
Outil/langage préféré
Recherche dans le journal d’audit Microsoft Purview
Defender for Cloud Apps
Microsoft Sentinel

Le reste de cette section fournit une brève présentation de chacune des options indiquées dans le tableau.

Espace de travail de supervision de l’administration

L’espace de travail de surveillance administrateur contient des rapports et des modèles sémantiques prédéfinis dans le service Power BI. C’est un moyen pratique pour les administrateurs Fabric et les administrateurs généraux d’afficher les données d’audit récentes et pour les aider à comprendre les activités des utilisateurs.

Try-it dans la documentation d’API

Try-it est un outil interactif qui vous permet de tester l’API REST Power BI directement dans la documentation Microsoft. Il s’agit d’un moyen simple d’explorer les API, car il ne nécessite pas d’autres outils ni de configuration sur votre machine.

Vous pouvez utiliser Try-it pour :

• Envoyer manuellement une demande à une API pour déterminer si elle renvoie les informations souhaitées.
• Découvrir comment l’URL est construite avant d’écrire un script.
• Vérifier les données de manière informelle.

Notes

Vous devez avoir une licence Power BI et être authentifié pour utiliser Try-it. Il suit le modèle d’autorisations standard, ce qui signifie que les API utilisateur s’appuient sur des autorisations utilisateur, et que les API d’administration nécessitent des autorisations d’administrateur Power BI. Vous ne pouvez pas vous authentifier avec Try-it en utilisant un principal de service.

Comme il est interactif, Try-it convient mieux à l’apprentissage, à l’exploration et aux nouveaux processus d’audit manuels.

PowerShell et Azure Cloud Shell

Vous pouvez créer et exécuter des scripts PowerShell de plusieurs façons.

Voici plusieurs options courantes.

• Visual Studio Code : éditeur de code source léger et moderne. Il s’agit d’un outil open source disponible gratuitement qui est pris en charge sur plusieurs plateformes, notamment Windows, macOS et Linux. Vous pouvez utiliser Visual Studio Code avec de nombreux langages, notamment PowerShell (avec l’extension PowerShell).
• Azure Data Studio : outil permettant de créer des scripts et des notebooks. Il s’appuie sur Visual Studio Code. Azure Data Studio est disponible indépendamment ou avec SQL Server Management Studio (SSMS). Il y a de nombreuses extensions, notamment une extension pour PowerShell.
• Azure Cloud Shell : alternative à l’utilisation locale de PowerShell. Vous pouvez accéder à Azure Cloud Shell à partir d’un navigateur.
• Azure Functions : alternative à l’utilisation locale de PowerShell. Azure Functions est un service Azure qui vous permet d’écrire et d’exécuter du code dans un environnement serverless. PowerShell est un des nombreux langages qu’il prend en charge.

Important

Nous vous recommandons d’utiliser la dernière version de PowerShell (PowerShell Core) pour tous les nouveaux travaux de développement. Vous devez cesser d’utiliser Windows PowerShell (qui ne peut pas exécuter PowerShell Core) et utiliser plutôt un des éditeurs de code modernes qui prennent en charge PowerShell Core. Faites attention quand vous faites référence à de nombreux exemples en ligne qui utilisent Windows PowerShell (version 5.1), car ils risquent de ne pas utiliser les dernières (et meilleures) approches de code.

Vous pouvez utiliser PowerShell de plusieurs façons. Pour plus d’informations sur cette décision technique, consultez Choisir des API ou des applets de commande PowerShell plus loin dans cet article.

De nombreuses ressources en ligne sont disponibles pour utiliser PowerShell, et il est souvent possible de trouver des développeurs expérimentés capables de créer et gérer des solutions PowerShell. PowerShell est un bon choix pour créer des processus d’audit à la fois manuels et automatisés.

Power BI Desktop

Parce que Power BI Desktop peut se connecter aux API, vous pouvez être tenté de l’utiliser pour créer votre solution d’audit. Toutefois, il y a de gros inconvénients et de grandes complexités.

• Accumulation d’historique : comme le journal d’activité Power BI fournit jusqu’à 30 jours de données, la création de votre solution d’audit entière implique d’accumuler au fil du temps un ensemble de fichiers qui stockent tous les événements historiques. L’accumulation de fichiers historiques est plus simple à réaliser avec d’autres outils.
• Gestion sécurisée des informations d’identification et des clés : de nombreuses solutions en ligne créées par des blogueurs de la communauté ne sont pas sécurisées, car elles codent en dur les informations d’identification et les clés en texte brut dans des requêtes Power Query. Bien que cette approche soit facile, elle n’est pas recommandée, car toute personne qui obtient votre fichier Power BI Desktop peut lire les valeurs. Vous ne pouvez pas stocker le mot de passe (quand vous utilisez l’authentification utilisateur) ou le secret (quand vous utilisez un principal de service) de manière sécurisée dans Power BI Desktop sauf si vous :
  • Utilisez un connecteur personnalisé qui a été développé avec le SDK Power Query. Par exemple, un connecteur personnalisé peut lire les valeurs confidentielles d’Azure Key Vault ou d’un autre service qui stocke la valeur chiffrée de manière sécurisée. Il y a aussi différentes options de connecteur personnalisé disponibles dans la communauté Power BI mondiale.
  • Utilisez l’option ApiKeyName, qui fonctionne bien dans Power BI Desktop. Toutefois, vous ne pouvez pas stocker la valeur de clé dans le service Power BI.
• Types de demandes : vous risquez d’être confronté à des limitations concernant ce que vous pouvez exécuter dans Power BI Desktop. Par exemple, Power Query ne prend pas en charge tous les types de demande d’API. Par exemple, seules les demandes GET et POST sont prises en charge avec la fonction Web.Contents. Pour l’audit, vous envoyez généralement des demandes GET.
• Possibilité d’actualisation : vous devez suivre des modèles de développement Power Query spécifiques pour pouvoir actualiser un modèle sémantique dans le service Power BI. Par exemple, l’option RelativePath doit être présente quand vous utilisez Web.Contents, pour que Power BI puisse vérifier correctement l’emplacement d’une source de données sans générer d’erreur dans le service Power BI.

Dans la plupart des cas, nous vous recommandons d’utiliser Power BI Desktop uniquement pour deux objectifs. Vous devez l’utiliser pour :

• Créer votre modèle de données à partir des données organisées existantes (plutôt que pour extraire initialement les données d’audit).
• Créer des rapports analytiques à partir de votre modèle de données.

Power Automate

Vous pouvez utiliser Power Automate avec Power BI de plusieurs façons. En ce qui concerne l’audit, vous pouvez utiliser Power Automate pour envoyer des demandes aux API REST Power BI, puis stocker les données extraites à l’emplacement de votre choix.

Conseil

Pour envoyer des demandes aux API REST Power BI, vous pouvez utiliser un connecteur personnalisé pour Power Automate afin d’authentifier et extraire de manière sécurisée les données d’audit. Vous pouvez aussi utiliser Azure Key Vault pour référencer un mot de passe ou un secret. Les deux options sont préférables au stockage des mots de passe et des secrets en texte brut dans le flux Power Automate.

Pour d’autres idées d’utilisation de Power Automate, recherchez Power BI dans les modèles Power Automate.

Service Azure préféré

Il y a plusieurs services Azure qui peuvent envoyer des demandes aux API REST Power BI. Vous pouvez utiliser votre service Azure préféré, par exemple :

• Azure Functions
• Azure Automation
• Azure Data Factory.
• Azure Synapse Analytics

Dans la plupart des cas, vous pouvez combiner un service de calcul qui gère la logique d’extraction des données avec un service de stockage qui stocke les données brutes (et les données organisées, selon les besoins). Les considérations relatives à la prise de décisions en matière d’architecture technique sont décrites plus loin dans cet article.

Outil et/ou langage préféré

Vous pouvez utiliser votre outil préféré et votre langage préféré pour envoyer des demandes aux API REST Power BI. Il s’agit d’une bonne approche si votre équipe maîtrise un outil ou un langage spécifique, par exemple :

• Python
• C# sur le .NET Framework. Vous pouvez aussi utiliser le SDK Power BI .NET, qui sert de wrapper par-dessus les API REST Power BI afin de simplifier certains processus et augmenter la productivité.
• JavaScript

Recherche dans le journal d’audit Microsoft Purview

Le portail de conformité Microsoft Purview (anciennement centre de conformité Microsoft 365) comprend une interface utilisateur qui vous permet de consulter les journaux d’audit et d’y faire des recherches. Les journaux d’audit unifiés comprennent Power BI et tous les autres services qui prennent en charge les journaux d’audit unifiés Microsoft 365.

Les données capturées dans le journal d’audit unifié sont exactement les mêmes que celles du journal d’activité Power BI. Quand vous effectuez une recherche dans le journal d’audit à partir du portail de conformité Microsoft Purview, votre demande est ajoutée à la file d’attente. La préparation des données peut prendre quelques minutes (ou plus, selon le volume de données).

Voici des façons courantes d’utiliser l’outil de recherche dans le journal d’audit. Vous pouvez :

• Sélectionner la charge de travail Power BI pour voir les événements d’une série de dates.
• Rechercher une ou plusieurs activités spécifiques, par exemple :
  • Rapport Power BI supprimé
  • Un accès administrateur ajouté à un espace de travail personnel dans Power BI
• Consulter les activités d’un ou de plusieurs utilisateurs.

Pour les administrateurs avec des autorisations suffisantes, l’outil de recherche dans le journal d’audit à partir du portail de conformité Microsoft Purview est une bonne option pour les processus d’audit manuels. Pour plus d’informations, consultez Portail de conformité Microsoft Purview plus loin dans cet article.

Interface utilisateur Defender for Cloud Apps

Defender for Cloud Apps est disponible pour les administrateurs dans Microsoft Defender XDR (portail Microsoft 365). Il comprend une interface utilisateur permettant de consulter les journaux d’activité de différents services cloud, notamment Power BI, et d’y faire des recherches. Il affiche les mêmes événements de journal que ceux du portail de conformité Microsoft Purview, en plus d’autres événements comme l’activité de connexion des utilisateurs à partir de Microsoft Entra ID.

L’interface du journal d’audit dans Defender for Cloud Apps est une bonne option pour les processus d’audit manuels. Pour plus d’informations, consultez Defender for Cloud Apps plus loin dans cet article.

Microsoft Sentinel et KQL

Microsoft Sentinel est un service Azure qui vous permet de collecter, de détecter, d’examiner les incidents et menaces de sécurité et d’y répondre. Power BI peut être configuré dans Microsoft Sentinel comme connecteur de données afin que les journaux d’audit soient diffusés en continu à partir de Power BI vers Microsoft Sentinel Azure Log Analytics (qui est un composant du service Azure Monitor). Vous pouvez utiliser le Langage de requête Kusto (KQL) pour analyser les événements du journal d’activité stockés dans Azure Log Analytics.

L’utilisation de KQL pour rechercher les données dans Azure Monitor est une bonne option pour consulter une partie du journal d’audit. C’est également une bonne option pour les processus d’audit manuels. Pour plus d’informations, consultez Microsoft Sentinel plus loin dans cet article.

Considérations relatives à la plateforme

Voici quelques points à prendre en compte pour savoir comment accéder aux données d’audit.

• Implémentez-vous un processus d’audit manuel ou automatisé ? Certains outils correspondent mieux au traitement manuel ou au traitement automatisé. Par exemple, un utilisateur exécute toujours la fonctionnalité Try-it de manière interactive, elle convient donc uniquement aux processus d’audit manuels.
• Comment allez-vous vous authentifier ? Les options ne prennent pas toutes en charge l’intégralité des options d’authentification. Par exemple, la fonctionnalité Try-it prend uniquement en charge l’authentification utilisateur.
• Comment allez-vous stocker les informations d’identification de manière sécurisée ? Différentes technologies ont différentes options pour stocker les informations d’identification. Pour plus d’informations, consultez Déterminer la méthode d’authentification plus loin dans cet article.
• Quelle technologie est déjà maîtrisée par votre équipe ? S’il y a un outil que votre équipe préfère et dont elle maîtrise l’utilisation, commencez par lui.
• Qu’est-ce que votre équipe peut prendre en charge ? Si une autre équipe prend en charge la solution déployée, déterminez si cette équipe peut le faire de manière adéquate. Tenez également compte du fait que vos équipes internes peuvent éventuellement prendre en charge un développement effectué par des consultants.
• Quel outil êtes-vous autorisé à utiliser ? Certains outils et technologies peuvent nécessiter une approbation. Peut-être en raison des coûts. Peut-être aussi en raison des stratégies de sécurité informatique.
• Quelle est votre préférence de planification ? Certaines technologies décident pour vous. D’autres fois, c’est à vous de prendre la décision. Par exemple, si vous choisissez d’écrire des scripts PowerShell, vous pouvez planifier leur exécution de différentes façons. À l’inverse, si vous utilisez un service cloud comme Azure Data Factory, la planification est intégrée.

Nous vous recommandons de passer en revue le reste de cet article avant de choisir une technologie pour accéder aux données d’audit.

Check-list : voici les décisions et actions clés à prendre en compte afin de choisir la technologie à utiliser pour accéder aux données d’audit :

• Discuter avec le personnel informatique : contactez les équipes informatiques pour savoir s’il y a des outils approuvés ou préférés.
• Explorer les options avec une petite preuve de concept : faites des essais avec une preuve de concept technique. Concentrez-vous d’abord sur l’apprentissage. Ensuite, concentrez-vous sur ce que avez choisi.

Déterminer la méthode d’authentification

La planification de l’authentification est une décision essentielle. C’est souvent un des aspects les plus difficiles quand vous débutez avec l’audit et le monitoring. Vous devez examiner attentivement les options disponibles pour prendre une décision éclairée.

Important

Consultez vos équipes informatiques et de sécurité à ce sujet. Prenez le temps d’apprendre les principes de base du fonctionnement de la sécurité dans Microsoft Entra ID.

Les API sur Internet ne nécessitent pas toutes une authentification. Toutefois, toutes les API REST Power BI nécessitent une authentification. Quand vous accédez aux données d’audit au niveau du locataire, le processus d’authentification est géré par la plateforme d’identité Microsoft. Il s’agit d’une évolution du service d’identité Microsoft Entra qui repose sur les protocoles standard du secteur.

Conseil

Le glossaire de termes de la plateforme d’identité Microsoft est une ressource qui vous aide à vous familiariser avec les concepts de base.

Avant de récupérer des données d’audit, vous devez d’abord vous authentifier, ce qu’on appelle la connexion. Les concepts d’authentification et d’autorisation sont distincts, mais liés. Un processus d’authentification vérifie l’identité de l’utilisateur qui fait la demande. Un processus d’autorisation accorde (ou refuse) l’accès à un système ou à une ressource en vérifiant ce que l’utilisateur ou le principal de service a le droit de faire.

Quand un utilisateur ou un principal de service s’authentifie, un jeton d’accès Microsoft Entra est émis à destination d’un serveur de ressources, comme une API REST Power BI ou une API Microsoft Graph. Par défaut, le jeton d’accès expire au bout d’une heure. Un jeton d’actualisation peut être demandé, si nécessaire.

Il y a deux types de jetons d’accès :

• Jetons utilisateur : émis pour le compte d’un utilisateur avec une identité connue.
• Jetons d’application uniquement : émis pour le compte d’une application Microsoft Entra (principal de service).

Pour plus d’informations, consultez Objets d’application et du principal de service dans Microsoft Entra ID.

Remarque

Une application Microsoft Entra est une configuration d’identité qui permet à un processus automatisé de s’intégrer à Microsoft Entra ID. Dans cet article, on parle d’inscription d’application. Le terme principal de service est également couramment utilisé dans cet article. Ces termes sont décrits plus en détail plus loin dans cet article.

Conseil

Le moyen le plus simple de s’authentifier est d’utiliser l’applet de commande Connect-PowerBIServiceAccount du module de gestion Power BI. Vous verrez sans doute d’autres cmdlets liées à l’authentification dans des articles et des billets de blog en ligne. Par exemple, les applets de commande Login-PowerBI et Login-PowerBIServiceAccount, qui sont des alias de l’applet de commande Connect-PowerBIServiceAccount. Il y a aussi l’applet de commande Disconnect-PowerBIServiceAccount, que vous pouvez utiliser pour vous déconnecter explicitement à la fin d’un processus.

Le tableau suivant décrit les deux options d’authentification.

Type d’authentification	Description	Usage prévu	Bon choix pour les processus d’audit manuels	Bon choix pour les processus d’audit automatisés
Authentification utilisateur	Connexion en tant qu’utilisateur avec le nom d’utilisateur principal (adresse e-mail) et un mot de passe.	Utilisation occasionnelle et interactive
Authentification d’un principal du service	Connexion en tant que principal de service avec un secret (clé) attribué à une inscription d’application.	Opérations courantes, planifiées et sans assistance

Chaque option d’authentification est décrite plus en détail dans la section suivante.

Authentification utilisateur

L’authentification utilisateur est utile dans les situations suivantes.

• Processus d’audit manuels : vous voulez exécuter un script en utilisant vos autorisations utilisateur. Les autorisations peuvent s’appliquer à deux niveaux, selon le type de demande d’API :
  • Autorisations d’administrateur pour les API d’administration : vous devez utiliser vos autorisations d’administrateur Power BI pour envoyer une demande à une API d’administration.
  • Autorisations utilisateur pour les API utilisateur : vous devez utiliser vos autorisations utilisateur Power BI pour envoyer une demande à une API utilisateur. Pour plus d’informations, consultez Choisir une API utilisateur ou une API d’administration.
• Connexion interactive : vous voulez vous connecter de manière interactive, ce qui implique d’indiquer votre adresse e-mail et votre mot de passe. Par exemple, vous devez vous connecter de manière interactive pour utiliser l’expérience Try-it, qui se trouve dans la documentation d’API Microsoft.
• Suivre les utilisateurs qui ont accédé aux métadonnées de locataire : quand des utilisateurs et administrateurs individuels envoient des demandes d’API, vous pouvez vérifier qui sont ces personnes. Quand vous vous authentifiez avec un principal de service (décrit par la suite), l’ID utilisateur capturé par le journal d’activité est l’ID d’application. Si plusieurs administrateurs s’authentifient avec le même principal de service, il peut être difficile de savoir quel administrateur a accédé aux données.
• Compte d’administrateur partagé : certaines équipes informatiques utilisent un compte d’administrateur partagé. Selon le mode d’implémentation et de contrôle du compte administrateur partagé, ce ne sera sans doute pas une meilleure pratique. Plutôt qu’un compte partagé, envisagez plutôt d’utiliser Microsoft Entra Privileged Identity Management (PIM), qui peut accorder des droits d’administrateur Power BI occasionnels et temporaires à un utilisateur.
• API qui prennent uniquement en charge l’authentification utilisateur : parfois, vous pouvez avoir besoin d’utiliser une API qui ne prend pas en charge l’authentification par un principal de service. Dans la documentation, chaque API indique si elle peut être appelée par un principal de service.

Important

Dans la mesure du possible, nous vous recommandons d’utiliser l’authentification du principal de service pour les processus automatisés.

Authentification d’un principal du service

Comme la plupart des organisations ont un seul locataire Microsoft Entra, les termes inscription d’application et principal de service ont tendance à être utilisés indifféremment. Quand vous inscrivez une application Microsoft Entra, il existe deux composants.

• Inscription d’application : une inscription d’application est globalement unique. Il s’agit de la définition globale d’une application Microsoft Entra inscrite qui peut être utilisée par plusieurs locataires. Une inscription d’application est également appelée application cliente ou acteur. En règle générale, le terme application cliente implique une machine utilisateur. Toutefois, ce n’est pas le cas pour les inscriptions d’application. Sur le portail Azure, les applications Microsoft Entra se trouvent dans la page Inscriptions d’applications de Microsoft Entra ID.
• Principal de service : un principal de service est la représentation locale de l’inscription d’application que vous utilisez dans votre locataire spécifique. Le principal de service est dérivé de l’application Microsoft Entra inscrite. Pour les organisations disposant de plusieurs locataires Microsoft Entra, la même inscription d’application peut être référencée par plusieurs principaux de service. Sur le portail Azure, les principaux de service se trouvent dans la page Applications d’entreprise de Microsoft Entra ID.

Comme le principal de service est la représentation locale, le terme authentification du principal de service désigne généralement les connexions.

Conseil

Votre administrateur Microsoft Entra peut vous dire qui dans votre organisation est autorisé à créer une inscription d’application et à y consentir.

L’authentification du principal de service est utile dans les situations suivantes.

• Processus d’audit automatisés : vous voulez exécuter un processus sans assistance selon une planification.
• Vous n’avez pas besoin de vous authentifier sur le service Power BI : il vous suffit de vous connecter et d’extraire les données. Un principal de service ne peut pas s’authentifier sur le service Power BI.
• Accès partagé aux données : vous (personnellement) n’êtes pas administrateur Power BI, mais vous êtes autorisé à utiliser un principal de service. Le principal de service est autorisé à exécuter des API d’administration pour récupérer des données au niveau du locataire (ou d’autres autorisations spécifiques).
• Utilisation par plusieurs administrateurs : vous voulez autoriser plusieurs administrateurs ou utilisateurs à utiliser le même principal de service.
• Bloqueurs techniques : il existe un bloqueur technique qui empêche l’utilisation de l’authentification utilisateur. Les bloqueurs techniques courants sont les suivants :
  • Authentification multifacteur (MFA) : les processus d’audit automatisés (qui s’exécutent sans assistance) ne peuvent pas s’authentifier avec un compte d’utilisateur quand l’authentification multifacteur est activée.
  • Synchronisation du hachage de mot de passe : Microsoft Entra ID exige une synchronisation du hachage de mot de passe pour qu’un compte d’utilisateur puisse s’authentifier. Parfois, le service informatique ou une équipe de cybersécurité peut désactiver cette fonctionnalité.

Objectif et convention de nommage de l’inscription d’application

Chaque inscription d’application doit avoir un nom clair qui décrit son objectif et l’audience cible (les personnes qui peuvent utiliser l’inscription d’application).

Implémentez une convention de nommage de type : <Charge de travail> - <Objectif> - <Audience cible> - <Type d’objet>

Voici les parties de la convention de nommage.

• Charge de travail : généralement équivalent à une source de données (par exemple, des données Power BI ou des données Microsoft Graph).
• Objectif : similaire au niveau d’autorisations (par exemple, Read et ReadWrite). Comme décrit ci-dessous, l’objectif vous aide à suivre le principe du moindre privilège quand vous créez des inscriptions d’application distinctes qui peuvent uniquement lire les données.
• Audience cible : facultatif. En fonction de la charge de travail et de l’objectif, l’audience cible vous permet de déterminer les utilisateurs prévus de l’inscription d’application.
• Type d’objet :EntraApp est inclus dans un souci de clarté.

Votre convention de nommage peut être plus spécifique si vous avez plusieurs locataires ou plusieurs environnements (par exemple, développement et production).

Le tableau suivant montre des exemples d’inscriptions d’application qui peuvent être utilisées pour extraire des données d’audit au niveau du locataire :

Nom de l’inscription d’application	Objectif	Public cible
PowerBIData-Read-AdminAPIs-EntraApp	Extraire les métadonnées du locataire pour l’audit et l’administration de Power BI. Les API d’administration sont toujours en lecture seule et il se peut qu’aucune autorisation ne leur ait été accordée dans Microsoft Entra ID (paramètre de tenant Power BI uniquement).	Administrateurs Power BI et centre d’excellence
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Gérer le locataire Power BI. Nécessite des autorisations de lecture/écriture pour créer ou mettre à jour des ressources.	Administrateurs Power BI et centre d’excellence
GraphData-Read-PowerBIAdministrators-EntraApp	Extraire les données d’utilisateurs et de groupes pour l’audit et l’administration de Power BI. Nécessite des autorisations de lecture.	Administrateurs Power BI et centre d’excellence

La gestion de plusieurs inscriptions d’application pour divers usages implique plus d’efforts. Toutefois, vous pouvez bénéficier de plusieurs avantages.

• Voir ce à quoi l’inscription d’application est destinée et pourquoi : quand vous voyez l’ID client de l’inscription d’application dans vos données d’audit, vous avez une idée de ce à quoi elle a été utilisée et pourquoi. C’est un avantage significatif de pouvoir créer des inscriptions d’application distinctes (au lieu d’en utiliser une seule pour tous les usages).
• Voir à qui l’inscription d’application est destinée : quand vous voyez l’ID client de l’inscription d’application dans vos données d’audit, vous avez une idée de qui l’a utilisée.
• Éviter de surprovisionner des autorisations : vous pouvez suivre le principe du moindre privilège en fournissant des inscriptions d’application distinctes à différents groupes de personnes qui ont des besoins différents. Vous pouvez éviter le surprovisionnement des autorisations en utilisant une inscription d’application en lecture seule quand les autorisations d’écriture ne sont pas nécessaires. Par exemple, vous aurez sans doute des utilisateurs en libre-service très compétents qui veulent collecter des données sur leurs modèles sémantiques. Ils doivent pouvoir accéder à un principal de service avec une autorisation de lecture. D’un autre coté, vous pouvez avoir des membres satellites du centre d’excellence travaillant pour l’équipe des finances qui gèrent programmatiquement les modèles sémantiques. Ils doivent pouvoir accéder à un principal de service avec une autorisation d’écriture.
• Savoir qui doit être en possession du secret : le secret de chaque inscription d’application doit être partagé uniquement avec les personnes qui en ont besoin. Quand le secret est permuté (décrit plus loin dans cette section), l’impact est plus faible si vous utilisez des inscriptions d’application distinctes pour différents besoins. C’est utile quand vous devez permuter le secret parce qu’un utilisateur quitte l’organisation ou change de rôle.

Autorisations d’inscription d’application

Une inscription d’application accède aux données et aux ressources de deux grandes façons. Cela implique des autorisations et un consentement.

• Autorisations d’application uniquement : l’accès et l’autorisation sont gérés par le principal de service sans utilisateur connecté. Cette méthode d’authentification est utile pour les scénarios d’automatisation. Quand vous utilisez des autorisations d’application uniquement, vous devez bien comprendre que les autorisations ne sont pas attribuées dans Microsoft Entra ID. À la place, les autorisations peuvent être attribuées de deux manières :
  • Pour exécuter des API d’administration : certains paramètres de locataire Power BI autorisent l’accès aux points de terminaison pour les API d’administration (qui renvoient des métadonnées d’audit à l’échelle du locataire). Pour plus d’informations, consultez Définir les paramètres de locataire Power BI plus loin dans cet article.
  • Pour exécuter des API utilisateur : les autorisations d’espace de travail et d’élément Power BI s’appliquent. Les autorisations Power BI standard contrôlent les données qui peuvent être renvoyées à un principal de service pendant l’exécution d’API utilisateur (qui renvoient des données d’audit basées sur les autorisations de l’utilisateur ou du principal de service qui appelle l’API).
• Autorisations déléguées : des autorisations basées sur l’étendue sont utilisées. Le principal de service accède aux données pour le compte de l’utilisateur actuellement connecté. Cela signifie que le principal de service peut accéder uniquement à ce à quoi l’utilisateur connecté peut accéder. N’oubliez pas que c’est un concept différent de l’authentification utilisateur uniquement décrite précédemment. Comme une application personnalisée est nécessaire pour gérer correctement la combinaison des autorisations utilisateur et d’application, les autorisations déléguées sont rarement utilisées pour les scénarios d’audit. Ce concept est généralement mal compris et de nombreuses inscriptions d’application sont surprovisionnées avec des autorisations.

Important

Dans cet article, l’accent est mis seulement sur l’authentification utilisateur ou l’authentification d’application uniquement. Les autorisations déléguées (avec un utilisateur interactif et le principal de service) peuvent jouer un rôle important pour incorporer programmatiquement le contenu Power BI. Toutefois, nous vous déconseillons fortement de configurer des autorisations déléguées pour extraire les données d’audit. Comme chaque API limite sa propre fréquence d’exécution (en utilisant une limitation), il n’est pas pratique d’avoir différents utilisateurs qui accèdent directement aux données d’audit brutes. À la place, nous vous recommandons d’extraire les données d’audit brutes une seule fois (avec un processus centralisé), puis de mettre les données d’audit organisées à la disposition des utilisateurs autorisés en aval.

Pour plus d’informations, consultez Inscrire une application Microsoft Entra plus loin dans cet article.

Secrets d’inscription d’application

Une inscription d’application a souvent un secret qui lui est attribué. Le secret est utilisé comme clé pour l’authentification et a une date d’expiration. Par conséquent, vous devez planifier la permutation régulière de la clé et sa transmission aux utilisateurs autorisés.

Vous devez également choisir avec soin l’emplacement où stocker le secret de manière sécurisée. Un coffre de mots de passe d’organisation, comme Azure Key Vault, est un excellent choix.

Conseil

Une autre approche est l’utilisation d’une identité managée. Une identité managée évite d’avoir à gérer les informations d’identification. Si vous voulez utiliser des services comme Azure Functions ou Azure Data Factory pour extraire les données, une identité managée est une bonne option.

Gérer les informations d’identification de manière sécurisée

Que vous utilisiez l’authentification utilisateur ou l’authentification du principal de service, l’un des plus grands défis est de gérer de manière sécurisée les mots de passe, les secrets et les clés.

Attention

La première règle est négligée par de nombreuses personnes : les mots de passe et les clés ne doivent jamais s’afficher en texte clair dans un script. De nombreux articles, blogs et exemples en ligne le font par souci de simplicité. Toutefois, il s’agit d’une mauvaise pratique qui doit être évitée. Toute personne qui obtient le script (ou le fichier) peut potentiellement accéder aux données auxquelles l’auteur a accès.

Voici plusieurs méthodes sécurisées pour gérer les mots de passe, les secrets et les clés.

• Intégrez Azure Key Vault ou un autre système de coffre de mots de passe d’organisation, dans la mesure du possible.
• Utilisez des informations d’identification et des chaînes sécurisées dans vos scripts PowerShell. Les informations d’identification fonctionnent à la fois pour l’authentification utilisateur et l’authentification du principal de service. Toutefois, vous ne pouvez pas utiliser d’informations d’identification si l’authentification multifacteur est activée pour un compte d’utilisateur.
• Demandez un mot de passe dans votre script PowerShell ou utilisez une authentification interactive avec un navigateur.
• Utilisez le module Secret Management pour PowerShell publié par Microsoft. Il peut stocker des valeurs dans un coffre local. Il peut également intégrer un coffre de clés Azure distant, ce qui est utile si plusieurs administrateurs de votre organisation travaillent avec les mêmes scripts.
• Créez un connecteur personnalisé pour Power BI Desktop afin de lui permettre de gérer de manière sécurisée les informations d’identification. Certains connecteurs personnalisés sont mis à disposition par des membres de la communauté (généralement sur GitHub).

Conseil

Nous vous recommandons de consulter vos équipes informatiques et de sécurité pour vous aider à choisir la meilleure méthode ou vérifier que votre solution gère les informations d’identification de manière sécurisée.

Microsoft Authentication Library

La prise en charge de la bibliothèque d’authentification Azure AD (ADAL) a pris fin en décembre 2022. Depuis, vous devez utiliser la Bibliothèque d’authentification Microsoft (MSAL). L’équipe de sécurité de votre organisation doit être familiarisée avec ce changement important.

Bien qu’il ne soit pas primordial pour les professionnels de Power BI de bien comprendre la transition vers MSAL, vous devez appliquer les recommandations suivantes.

• Utilisez la dernière version du module de gestion Power BI quand vous vous authentifiez avec l’applet de commande PowerShell Connect-PowerBIServiceAccount. Il est passé d’ADAL à MSAL dans la version 1.0.946 (26 février 2021).
• Utilisez le point de terminaison Microsoft Entra V2 quand vous vous authentifiez directement dans votre script. Le point de terminaison Microsoft Entra V2 utilise MSAL, tandis que le point de terminaison Microsoft Entra V1 utilise ADAL.
• Arrêtez d’utiliser les API et les modules dépréciés. Pour plus d’informations, consultez API et modules dépréciés plus loin dans cet article.
• Si vous trouvez une solution en ligne de la communauté, vérifiez qu’elle utilise MSAL pour l’authentification au lieu d’ADAL.

Check-list : voici les décisions et actions clés à prendre en compte pour choisir comment gérer l’authentification :

• Choisir le type d’authentification à utiliser : déterminez si l’authentification utilisateur ou l’authentification du principal de service est la plus appropriée, selon le type de solution d’audit que vous voulez créer.
• Planifier les inscriptions d’application dont vous avez besoin : tenez compte de vos besoins, charges de travail et audience cible (les utilisateurs de chaque inscription d’application). Planifiez le nombre d’inscriptions d’application que vous devez créer pour répondre à ces besoins.
• Créer une convention de nommage pour les inscriptions d’application : configurez une convention de nommage qui facilite la compréhension de l’objectif prévu et des utilisateurs prévus de chaque inscription d’application.
• Planifier la gestion sécurisée des informations d’identification : réfléchissez à des moyens de gérer de manière sécurisée les mots de passe, les secrets et les clés. Déterminez la documentation et la formation éventuellement nécessaires.
• Vérifier l’utilisation de MSAL : déterminez s’il existe des solutions d’audit manuelles ou automatisées qui s’appuient sur ADAL. Si nécessaire, créez un plan pour réécrire ces solutions afin d’utiliser la nouvelle bibliothèque d’authentification MSAL.

Choisir une API utilisateur ou une API d’administration

Quand vous voulez récupérer des données d’audit, vous devez utiliser le bon type d’API.

Il y a deux types d’API à prendre en compte.

• API utilisateur : vous utilisez les autorisations de l’utilisateur connecté (ou du principal de service) pour envoyer des demandes à l’API. Par exemple, l’API utilisateur peut vous permettre de renvoyer la liste des modèles sémantiques d’un espace de travail. L’autorisation de lire les modèle sémantique peut être accordée à un rôle d’espace de travail ou pour chaque élément. Vous pouvez exécuter les API utilisateur de deux façons :
  • Authentification utilisateur : l’utilisateur connecté doit être autorisé à accéder à l’espace de travail ou à l’élément.
  • Authentification du principal de service : le principal de service doit être autorisé à accéder à l’espace de travail ou à l’élément.
• API d’administration : vous l’utilisez pour récupérer les métadonnées du locataire. On parle parfois d’étendue organisationnelle. Par exemple, vous utilisez une API d’administration pour renvoyer la liste de tous les modèle sémantiques dans le locataire. Vous pouvez exécuter les API d’administration de deux façons :
  • Authentification utilisateur : l’utilisateur connecté doit être administrateur Power BI pour pouvoir exécuter les API d’administration.
  • Authentification du principal de service : le principal de service doit avoir l’autorisation d’exécuter les API d’administration (sans dépendre des autorisations de sécurité comme l’API utilisateur).

Conseil

Toutes les API d’administration appartiennent au groupe d’opérations Administrateur. Une API qui a le suffixe As Admin est une API d’administration. Toutes les autres API sont des API utilisateur.

Imaginons que vous devez obtenir une liste de modèles sémantiques. Le tableau suivant présente six options d’API que vous pouvez utiliser pour cela. Quatre options sont des API utilisateur et deux des API d’administration. L’étendue et le nombre d’éléments renvoyés diffèrent selon l’API que vous choisissez.

Nom de l’API	Type d’API	Portée	Nombre de modèles sémantiques
Get Dataset	Utilisateur	Espace de travail personnel	Une
Obtenir des jeux de données	Utilisateur	Espace de travail personnel	Tous
Get Dataset in Group	Utilisateur	Un espace de travail	Un, à condition que l’utilisateur connecté ait l’autorisation de lire le modèle sémantique
Get Datasets in Group	Utilisateur	Un espace de travail	Tous, à condition que l’utilisateur connecté ait l’autorisation de lire chaque modèle sémantique
Get Datasets in Group as Admin	Admin	Un espace de travail	Tous
Get Datasets as Admin	Admin	Locataire entier	Tous

Notes

Certains noms d’API utilisent le terme Group pour référencer un espace de travail. Ce terme vient du modèle de sécurité Power BI d’origine, qui s’appuyait sur des groupes Microsoft 365. Bien que le modèle de sécurité Power BI ait considérablement évolué au fil des ans, les noms d’API existants sont restés les mêmes pour éviter de casser les solutions existantes.

Pour plus d’informations sur les paramètres de locataire, consultez Définir les paramètres de locataire Power BI plus loin dans cet article.

Check-list : voici les décisions et actions clés à prendre en compte pour choisir s’il faut utiliser une API utilisateur ou une API d’administration :

• Se reporter aux exigences de données : collectez et documentez les principales exigences métier d’une solution d’audit. En fonction du type de données dont vous avez besoin, déterminez si une étendue utilisateur ou une étendue organisationnelle est plus appropriée.
• Tester les résultats : effectuez des essais. Testez l’exactitude des résultats renvoyés par les différentes API.
• Passer en revue les autorisations : pour toutes les solutions d’audit existantes, vérifiez que les autorisations sont attribuées correctement aux administrateurs Power BI et aux principaux de service. Pour les nouvelles solutions d’audit, confirmez la méthode d’authentification à utiliser.

Choisir des API ou des applets de commande PowerShell

Une des décisions clés que vous devez prendre est s’il faut utiliser les applets de commande PowerShell disponibles pour les données spécifiques que vous voulez récupérer. Cette décision est importante si vous avez décidé d’utiliser PowerShell pour accéder aux données d’audit.

PowerShell est une solution d’automatisation des tâches. Le terme PowerShell est un terme collectif qui désigne le langage de script, une application d’interpréteur de commandes en ligne de commande et un framework de gestion de la configuration. PowerShell Core est la dernière version de PowerShell, et s’exécute sur Windows, Linux et macOS.

Une applet de commande PowerShell est une commande qui effectue une action. Un module PowerShell est un package qui contient des membres PowerShell, comme des applets de commande, des fournisseurs, des fonctions, des workflows, des variables et des alias. Vous téléchargez et installez des modules.

Un module PowerShell crée une couche d’abstraction sur les API. Par exemple, l’applet de commande Get-PowerBIActivityEvent récupère (ou obtient) les événements d’audit d’un locataire Power BI. Cette applet de commande PowerShell récupère ses données à partir de l’API REST Get Activity Events. En règle générale, il est plus simple de débuter en utilisant les applets de commande, car elles simplifient l’accès aux API sous-jacentes.

Une partie seulement des API est disponible sous forme d’applets de commande PowerShell. Quand vous développerez l’ensemble de votre solution d’audit, vous utiliserez probablement une combinaison d’applets de commande et d’API. Le reste de cette section vous aide à choisir comment accéder aux données.

Modules PowerShell

Microsoft a publié deux modules PowerShell qui contiennent des applets de commande liées à Power BI. Il s’agit du module de gestion Power BI et du module de passerelle de données. Ces modules PowerShell jouent le rôle de wrapper d’API au-dessus des API REST Power BI sous-jacentes. L’utilisation de ces modules PowerShell peut faciliter l’écriture de scripts.

Conseil

En plus des modules publiés par Microsoft, des modules et scripts PowerShell sont publiés gratuitement (généralement sur GitHub) par des membres de la communauté Power BI, des partenaires et des MVP (Microsoft Most Valued Professionals).

Commencer par une solution de la communauté peut être très utile pour créer votre solution d’audit de bout en bout. Si vous choisissez d’utiliser une solution disponible gratuitement, veillez à la tester complètement. Familiarisez-vous avec son fonctionnement pour pouvoir gérer efficacement votre solution au fil du temps. Votre service informatique peut avoir des critères concernant l’utilisation de solutions de la communauté accessibles au public.

Module de gestion Power BI

Le module de gestion Power BI est un module cumulatif qui contient des modules Power BI spécifiques pour l’administration, les capacités, les espaces de travail, etc. Vous pouvez choisir d’installer le module cumulatif pour obtenir tous les modules, ou vous pouvez installer des modules spécifiques. Tous les modules de gestion Power BI sont pris en charge sur Windows PowerShell et PowerShell Core.

Important

Nous vous recommandons d’arrêter d’utiliser Windows PowerShell (qui ne peut pas exécuter PowerShell Core). Utilisez plutôt un des éditeurs de code modernes qui prend en charge PowerShell Core. L’ISE (environnement de script intégré) Windows PowerShell est uniquement capable d’exécuter PowerShell version 5.1, qui n’est plus mis à jour. Windows PowerShell étant maintenant déprécié, nous vous recommandons d’utiliser PowerShell Core pour tout nouveau travail de développement.

Voici plusieurs applets de commande couramment utilisées pour récupérer des données d’audit.

Module de gestion	Applet de commande	Objectif
Profil	Connect-PowerBIServiceAccount	Authentifier un utilisateur ou un principal de service Power BI.
Admin	Get-PowerBIActivityEvent	Voir ou extraire des événements du journal d’activité Power BI pour le locataire.
Espaces de travail	Get-PowerBIWorkspace	Compiler une liste d’espaces de travail.
Rapports	Get-PowerBIReport	Compiler une liste de rapports pour un espace de travail ou le locataire.
Données	Get-PowerBIDataset	Compiler une liste de modèles sémantiques pour un espace de travail ou le locataire.
Profil	Invoke-PowerBIRestMethod	Envoyer une demande d’API REST (commande). Cette applet de commande est une bonne option, car elle peut appeler n’importe quelle API REST Power BI. C’est aussi un bon choix si vous voulez utiliser la forme d’authentification plus simple avec l’applet de commande Connect-PowerBIServiceAccount et que vous voulez pouvoir appeler une API qui n’a pas d’applet de commande PowerShell correspondante. Pour plus d’informations, consultez Considérations sur l’utilisation des applets de commande PowerShell plus loin dans cette section.

Conseil

D’autres applets de commande sont disponibles pour gérer et publier du contenu. Toutefois, cet article se concentre sur la récupération des données d’audit.

Vous pouvez télécharger le module de gestion Power BI à partir de PowerShell Gallery. Le moyen le plus simple d’installer des modules est d’utiliser PowerShellGet.

Nous vous recommandons d’installer le module cumulatif de gestion Power BI. De cette façon, toutes les applets de commande dont vous pouvez avoir besoin sont disponibles. Au minimum, vous avez besoin du module Profile (pour l’authentification) et de tous les modules spécifiques qui contiennent les applets de commande que vous voulez utiliser.

Attention

Veillez à maintenir les modules à jour sur chaque serveur, machine utilisateur et service cloud (comme Azure Automation) où vous utilisez PowerShell. Si les modules ne sont pas mis à jour régulièrement, des erreurs ou des problèmes imprévisibles peuvent se produire. Certains outils (comme Visual Studio Code) vous aident à maintenir les modules à jour. Sachez également que PowerShellGet ne désinstalle pas automatiquement les anciennes versions d’un module quand vous installez ou mettez à jour une version plus récente. Il installe les versions plus récentes à côté des versions antérieures. Nous vous recommandons de rechercher les versions installées et de désinstaller régulièrement les versions antérieures.

Module de passerelle de données

Le module de passerelle de données contient des applets de commande qui récupèrent des données sur une passerelle de données locale et ses sources de données. Le module de passerelle de données est pris en charge uniquement sur PowerShell Core. Il n’est pas pris en charge sur Windows PowerShell.

Contrairement au module de gestion Power BI (décrit précédemment), le module de passerelle de données n’a aucune applet de commande d’administration. La plupart des applets de commande (et les API de passerelle correspondantes) nécessitent que l’utilisateur ait des droits d’administrateur de passerelle.

Avertissement

Il n’est pas possible d’attribuer un principal de service comme administrateur de passerelle (même si le principal de service est membre d’un groupe de sécurité). Par conséquent, prévoyez d’utiliser des informations d’identification utilisateur pour récupérer des informations sur les passerelles de données.

Voici plusieurs applets de commande du module de passerelle de données que vous pouvez utiliser pour récupérer des données d’audit.

Applet de commande	Objectif
Connect-DataGatewayServiceAccount	Authentifier un utilisateur Power BI (nécessite généralement que l’utilisateur appartienne au rôle d’administrateur de passerelle).
Get-DataGatewayCluster	Compiler une liste de clusters de passerelle.
Get-DataGatewayClusterDataSource	Compiler une liste de sources de données pour un cluster de passerelle.
Get-DataGatewayInstaller	Vérifier les utilisateurs qui sont autorisés à installer et inscrire des passerelles dans l’organisation.

Vous pouvez télécharger le module de passerelle de données à partir de PowerShell Gallery.

Techniques d’utilisation de PowerShell

Vous pouvez utiliser PowerShell de plusieurs façons. La décision que vous prenez est importante.

Le tableau suivant décrit trois techniques différentes pour utiliser PowerShell.

Technique	Description	Exemple
Utiliser des applets de commande PowerShell pour simplifier l’authentification et appeler directement des API. Approche recommandée	Avec cette technique, vous avez un juste milieu entre simplicité et flexibilité. L’applet de commande Invoke-PowerBIRestMethod est disponible à partir du module Profile de gestion Power BI. Cette applet de commande est souvent désignée comme un couteau suisse, car vous pouvez l’utiliser pour appeler n’importe quelle API REST Power BI. L’avantage de cette technique est que vous pouvez simplifier l’authentification, et appeler n’importe laquelle des API REST Power BI. Nous vous recommandons vivement d’utiliser cette technique.	Après l’authentification avec l’applet de commande Connect-PowerBIServiceAccount, utilisez l’applet de commande Invoke-PowerBIRestMethod pour récupérer les données de votre API préférée (par exemple, Get Pipeline Users As Admin).
Utiliser le plus possible les applets de commande PowerShell, à la fois pour l’authentification et pour la récupération des données.	Avec cette technique, PowerShell est largement utilisé. PowerShell est utilisé pour coordonner l’exécution du script, et les modules PowerShell sont utilisés dès que possible pour accéder aux données. Cela crée une grande dépendance vis-à-vis de PowerShell sous plusieurs aspects.	Après l’authentification avec l’applet de commande Connect-PowerBIServiceAccount, utilisez une applet de commande (par exemple, Get-PowerBIActivityEvent) pour récupérer les données.
Utiliser PowerShell uniquement pour coordonner l’exécution du processus. Les modules PowerShell sont utilisés le moins possible.	Avec cette technique, il y a moins de dépendance vis-à-vis de PowerShell en tant qu’outil, car son utilisation principale est d’orchestrer les appels d’API. Un seul module PowerShell générique est utilisé pour accéder aux API (aucun des modules compris dans le module de gestion Power BI n’est utilisé).	Après l’authentification avec la bibliothèque d’authentification Microsoft (MSAL), appelez votre API préférée (par exemple, Get Pipeline Users As Admin) avec l’applet de commande Invoke-RestMethod générique pour récupérer les données.

Dans le tableau ci-dessus, la première technique décrit une approche qui établit le juste milieu entre facilité d’utilisation et flexibilité. Cette approche répond aux besoins de la plupart des organisations, c’est pourquoi elle est recommandée. Certaines organisations peuvent avoir des stratégies informatiques existantes et des préférences du personnel qui influencent l’utilisation de PowerShell.

Conseil

Vous pouvez utiliser l’applet de commande PowerShell Invoke-ASCmd pour créer et exécuter des scripts DAX, XMLA et TMSL. Toutefois, ces cas d’usage ne sont pas décrits dans cet article. Pour plus d’informations sur l’interrogation des vues de gestion dynamique (DMV), consultez Audit au niveau des données.

Les utilisateurs techniques (et les administrateurs) peuvent utiliser les modules de gestion Power BI pour récupérer des données ou automatiser certains aspects de la gestion de contenu.

• Pour les administrateurs : définissez le paramètre -Scope sur Organization pour accéder aux entités de l’ensemble du locataire (par exemple, pour récupérer la liste de tous les espaces de travail).
• Pour les utilisateurs techniques : définissez le paramètre -Scope sur Individual (ou omettez le paramètre) pour accéder aux entités qui appartiennent à l’utilisateur (par exemple, pour récupérer la liste des espaces de travail auxquels l’utilisateur a l’autorisation d’accéder).

Imaginons que vous devez obtenir une liste de modèles sémantiques. Si vous choisissez d’utiliser directement les API, vous devez spécifier l’API à appeler. Toutefois, si vous choisissez d’utiliser l’applet de commande Get-PowerBIDataset, vous pouvez définir le paramètre -Scope pour récupérer la liste des modèles sémantiques propre à l’utilisateur ou au locataire. Le choix que vous faites dépend de comment vous avez décidez d’utiliser PowerShell (décrit dans le tableau précédent).

Le tableau suivant décrit comment les paramètres utilisés dans l’applet de commande PowerShell se traduisent en appels PowerShell d’API.

Paramètres d’applet de commande	API que l’applet de commande utilise	Type d’API	Portée	Éléments récupérés
-DatasetID {DatasetID} -Scope Individual	Get Dataset	Utilisateur	Espace de travail personnel	Un modèle sémantique
-Scope Individual	Obtenir des jeux de données	Utilisateur	Espace de travail personnel	Tous les modèles sémantiques
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Get Dataset in Group	Utilisateur	Un espace de travail	Un modèle sémantique, à condition que l’utilisateur connecté ait l’autorisation de lire le modèle sémantique
-GroupID {WorkspaceID}	Get Datasets in Group	Utilisateur	Un espace de travail	Tous les modèles sémantiques, à condition que l’utilisateur connecté ait l’autorisation d’accéder à l’espace de travail et de lire le modèle sémantique
-GroupID {WorkspaceID} -Scope Organization	Get Datasets in Group as Admin	Admin	Un espace de travail	Tous les modèles sémantiques
-Scope Organization	Get Datasets as Admin	Admin	Locataire entier	Tous les modèles sémantiques

Considérations sur l’utilisation des applets de commande PowerShell

Les applets de commande PowerShell Power BI sont plus simples à utiliser, car elles éliminent une partie de la complexité des appels d’API REST.

Voici quelques-unes des façons dont les applets de commande simplifient l’accès aux données d’audit.

• Authentification : la méthode la plus simple de s’authentifier dans un script PowerShell est d’utiliser l’applet de commande Connect-PowerBIServiceAccount.
• Simplicité : la prise en main est plus simple, car les techniques de récupération des données d’audit sont simples. Quand vous utilisez l’applet de commande Get-PowerBIActivityEvent, vous récupérez une journée de données d’audit. Toutefois, quand vous appelez directement l’API REST Get Activity Events, vous récupérez une heure de données d’audit. Par conséquent, quand vous utilisez l’API REST pour récupérer un jour de données d’audit, vous devez utiliser une boucle pour appeler l’API 24 fois afin d’extraire chaque heure de la journée.
• Pagination des grands jeux de résultats : les grands jeux de résultats sont récupérés efficacement par pagination. La pagination consiste à récupérer les résultats segment par segment. Les applets de commande gèrent automatiquement la pagination pour vous. Toutefois, quand vous utilisez directement les API REST, votre script doit vérifier s’il y a un jeton de continuation pour déterminer s’il y a d’autres résultats qui suivent. Le script doit continuer à récupérer des blocs de résultats jusqu’à ce qu’il n’y ait plus de jeton de continuation. Pour obtenir un exemple d’utilisation de jeton de continuation, consultez API REST Activity Events.
• Expiration des jetons d’accès : pendant l’authentification, un jeton d’accès est renvoyé. Par défaut, il expire au bout d’une heure. Les applets de commande gèrent l’expiration des jetons d’accès pour vous. De cette façon, vous n’avez pas besoin d’écrire de logique pour demander un jeton d’actualisation.
• Mise en forme : le format des données renvoyées par une applet de commande est légèrement plus agréable que celui des données renvoyées par l’API REST. La sortie est plus conviviale. Pour les processus d’audit automatisés, ce n’est pas un problème. Toutefois, pour les processus d’audit manuels, vous pouvez préférez la mise en forme plus agréable.

Considérations sur l’utilisation directe des API REST

Il peut y avoir des avantages à appeler directement les API REST Power BI.

• Bien plus d’API disponibles : il y a plus d’API REST disponibles que d’applets de commande PowerShell. Toutefois, ne négligez pas la flexibilité de l’applet de commande Invoke-PowerBIRestMethod, que vous pouvez utiliser pour appeler n’importe laquelle des API REST Power BI.
• Fréquence des mises à jour : Microsoft met à jour les API REST plus souvent que les modules PowerShell. Par exemple, si un nouvel attribut est ajouté à la réponse de l’API Get Dataset, cela peut prendre un certain temps pour qu’il soit disponible dans les résultats de l’applet de commande Get-PowerBIDataset.
• Moins de dépendance de langage/d’outil : quand vous utilisez directement les API REST (au lieu d’une applet de commande), vous n’avez pas besoin d’utiliser PowerShell. Vous pouvez également choisir d’utiliser PowerShell uniquement pour orchestrer l’appel de nombreuses API dans un script. En supprimant (ou en évitant) toute dépendance vis-à-vis de PowerShell, vous avez la liberté de réécrire votre logique dans un autre langage si vous en avez envie par la suite. Quand votre équipe informatique ou de développement a de fortes préférences pour certains outils et langages, vous devez peut-être opter pour une moindre dépendance.

Quelle que soit la méthode utilisée, les API REST peuvent changer au fil du temps. Quand une technologie évolue, les API (et modules PowerShell) peuvent être dépréciées et remplacées. Par conséquent, nous vous recommandons de créer délibérément des scripts simples à gérer et résilients aux changements.

Check-list : voici les décisions et actions clés à prendre en compte pour choisir si vous accédez aux API REST directement ou en utilisant des applets de commande PowerShell :

• Consulter le service informatique sur l’utilisation de PowerShell : contactez la ou les équipes informatiques concernées pour déterminer s’il y a des exigences ou des préférences internes concernant l’utilisation de PowerShell.
• Déterminer comment utiliser PowerShell : déterminez les techniques PowerShell à utiliser, et si vous voulez augmenter ou réduire intentionnellement votre dépendance vis-à-vis de PowerShell. Déterminez si une communication interne ou une formation est nécessaire.
• Mettre à niveau vers PowerShell Core : faites une recherche de PowerShell Core. Déterminez si les machines des administrateurs doivent être mises à jour. Déterminez les scripts existants qui doivent être testés. Déterminez si les administrateurs ou les développeurs ont besoin d’une formation supplémentaire pour mettre à niveau leurs compétences.
• Déterminer les modules PowerShell à utiliser : déterminez si vous allez utiliser les modules de gestion Power BI et/ou le module de passerelle de données.
• Déterminer si les projets de la communauté sont autorisés : déterminez si vous êtes autorisé (ou même encouragé) à utiliser les modules PowerShell disponibles en ligne (par rapport aux modules publiés par Microsoft). Consultez le service informatique pour déterminer s’il y a des critères concernant les projets de la communauté obtenus en ligne.
• Clarifier la prise en charge des projets de la communauté : si les projets de la communauté PowerShell sont autorisés, déterminez qui est responsable de leur prise en charge une fois utilisés en interne.
• Effectuer une petite preuve de concept : faites des essais avec une preuve de concept technique. Confirmez les outils clients et la méthode que vous préférez pour accéder aux données.
• Déterminer comment prendre en charge les utilisateurs avancés : réfléchissez à la manière de prendre en charge les utilisateurs techniques qui créent l’automatisation eux-mêmes avec des API utilisateur.

Déterminer où stocker les données d’audit

Quand vous planifiez la création d’une solution d’audit de bout en bout, vous devez choisir où stocker les données brutes (et les données organisées, qui sont traitées dans la section suivante). Vos décisions concernant le stockage des données sont liées à vos préférences en matière de gestion de l’intégration des données.

Quand vous extrayez des données d’audit brutes, restez simple. Nous vous recommandons de ne pas sélectionner d’attributs spécifiques, ne pas effectuer de transformations ni appliquer une mise en forme quand vous extrayez initialement les données. À la place, extrayez tous les attributs disponibles et stockez les données dans leur état d’origine.

Voici plusieurs raisons pour lesquelles le stockage des données brutes dans leur état d’origine est une bonne pratique.

• Toutes les données sont disponibles dans l’historique : de nouveaux attributs et de nouveaux types d’événements seront disponibles au fil du temps. Le stockage de toutes les données brutes est un bon moyen de toujours avoir accès aux données qui étaient disponibles au moment où vous les avez extraites. Même si vous vous rendez compte longtemps après (des semaines ou des mois) que de nouveaux attributs de données sont disponibles, vous pouvez toujours les analyser historiquement, car vous les avez capturés dans les données brutes.
• Résilience au changement : si le format des données brutes change, le processus qui extrait les données n’est pas impacté. Comme certaines données d’audit sont temporelles, vous devez concevoir un processus d’extraction de données qui n’échoue pas en cas de changement dans la source.
• Rôles et responsabilités : différents membres d’équipe (comme les ingénieurs Données ou les administrateurs généraux) peuvent être responsables de la création des processus d’accès, d’extraction et de stockage des données d’audit brutes. La simplification du processus d’extraction de données facilite la collaboration de plusieurs équipes.

Voici quelques options de stockage des données brutes.

• Lac de données ou stockage d’objets : un service cloud de type OneLake spécialisé dans le stockage des fichiers de n’importe quelle structure. C’est un choix idéal pour stocker les données d’audit brutes. Dans une architecture de lac de données, les données brutes doivent être stockées dans la couche bronze.
• Système de fichiers : un système de fichiers (comme Windows ou Linux) est un choix courant pour stocker les données d’audit brutes.
• Base de données : vous pouvez stocker des données JSON dans une base de données relationnelle, comme Azure SQL Database. Toutefois, cette option est moins courante qu’un lac de données ou un système de fichiers. En effet, l’interrogation et la maintenance des données JSON peuvent devenir complexes et coûteuses, en particulier quand les volumes de données augmentent.

Conseil

Quand vous utilisez un lac de données, un stockage d’objets ou un système de fichiers, nous vous recommandons de stocker les données d’une manière facile à organiser et à sécuriser. Déterminez clairement aussi si les données comprennent des événements (qui sont généralement ajoutés) ou s’il s’agit d’un instantané dans le temps (qui nécessite la sélection d’une date pour l’analyse).

Imaginons une zone de données brutes dans un lac de données. La zone a une hiérarchie de dossiers pour stocker les données du journal d’activité : Raw > ActivityLog > YYYY > MM. Les dossiers sont partitionnés par année et par mois. Un fichier stocké dans le dossier du mois utilise le format suivant : PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. YYYYMMDD représente les données réelles et YYYYMMDDTTTT l’horodatage d’extraction. En ajoutant l’horodatage d’extraction, vous pouvez déterminer le fichier le plus récent (au cas où vous deviez réextraire les données). Par exemple, si vous extrayez des données à 9 h (UTC) le 25 avril 2023 pour une activité le 23 avril 2023, le nom de fichier est PBIActivityLog-20230523-202305250900.

Nous vous recommandons vivement d’utiliser une technologie qui autorise l’écriture des données brutes dans un stockage immuable. Le stockage immuable garantit qu’une fois les données écrites, elles ne peuvent pas être remplacées ni supprimées. Cette distinction est importante pour les auditeurs et vous permet de garantir que les données brutes sont fiables.

Vous devez également réfléchir à la façon de stocker les données brutes de manière sécurisée. En règle générale, très peu d’utilisateurs ont besoin d’accéder aux données brutes. L’accès aux données brutes est généralement fourni en fonction des besoins, habituellement aux ingénieurs Données et aux administrateurs système. Vos auditeurs internes pourraient également avoir besoin d’un accès. Les membres d’équipe chargés de créer les données organisées (décrites ci-dessous) ont également besoin d’accéder aux données brutes.

Voici quelques considérations pour vous aider à choisir votre stockage de données brutes.

• S’agit-il d’un processus d’audit manuel ou automatisé ? Un processus d’audit automatisé a généralement des exigences plus strictes sur la façon de stocker les données et où les stocker.
• Le sujet est-il particulièrement sensible ? Selon le type de données et leur niveau de confidentialité, votre organisation peut avoir des exigences sur la façon de stocker les données et où les stocker. Les données d’audit Power BI contiennent des informations qui identifient les utilisateurs et les adresses IP. Elles doivent donc être stockées dans une zone sécurisée.
• Y a-t-il une technologie de stockage préférée ? Il risque d’y avoir une technologie de stockage existante dans l’organisation. Cela constitue alors un choix logique.
• Les utilisateurs accèdent-ils directement au stockage ? Le modèle de sécurité est une considération importante. En règle générale, très peu d’utilisateurs ont accès aux données brutes. L’accès aux données organisées est généralement donné aux créateurs de contenu Power BI qui sont chargés de créer le modèle de données centralisé (le modèle sémantique qui sert de couche pour la création de rapports).
• Avez-vous des exigences de résidence des données ? Certaines organisations ont des exigences légales ou réglementaires de résidence des données pour stocker les données dans une région de données spécifique.
• Comment les données sont-elles organisées ? L’utilisation de l’architecture de médaillon est une pratique courante, surtout dans les implémentations de lacs et lakehouse de données. L’objectif est de stocker vos données dans des couches de données bronze, argent et or. La couche bronze contient les données brutes d’origine. La couche argent contient des données validées et dédupliquées utilisées pour les transformations. La couche or contient les données organisées et hautement affinées prêtes à l’analyse.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier l’emplacement de stockage des données brutes :

• Consulter le service informatique : contactez la ou les équipes informatiques appropriées pour déterminer s’il y a des processus existants pour extraire les données d’audit brutes. Si c’est le cas, déterminez si vous pouvez accéder aux données existantes. Si un nouveau processus d’extraction de données est nécessaire, déterminez s’il y a des préférences ou des exigences concernant l’emplacement où les données doivent être stockées.
• Déterminer où stocker les données brutes : déterminez l’emplacement et la structure de stockage les mieux adaptés pour stocker les données brutes.
• Déterminer les exigences de résidence des données : déterminez s’il y a des exigences légales ou réglementaires concernant l’emplacement de stockage des données.
• Créer une structure de dossiers et une convention de nommage : déterminez la convention de nommage à utiliser pour les fichiers de données brutes, y compris la structure des dossiers. Ajoutez ces détails dans votre documentation technique.
• Réfléchir au fonctionnement de la sécurité des données brutes : quand vous concevez l’emplacement de stockage des données brutes, déterminez qui doit accéder aux données et comment accorder l’accès.

Planifier la création de données organisées

Les données organisées prennent en charge l’analyse et sont conçues pour être conviviales. Vous devez prendre des décisions sur la façon dont sont créées les données organisées et où. La technologie que vous choisissez pour stocker les données organisées peut être une des technologies listées dans la section précédente.

L’objectif des données organisées est de transformer les données dans un format plus convivial, optimisé pour l’analyse et la création de rapports. Elles constituent la source de données d’un modèle de données Power BI, ce qui signifie que vous utilisez un modèle de données Power BI pour analyser l’utilisation de Power BI dans votre organisation. Les directives fondamentales des modèles de données s’appliquent : vous devez adopter une conception de schéma en étoile, qui est optimisée pour les performances et la facilité d’utilisation.

Vous avez plusieurs façon de créer des données organisées. Vous devez décider comment effectuer l’intégration des données et où appliquer en amont les transformations qui préparent les données pour les charger dans un schéma en étoile.

Lac de données

Vous pouvez appliquer les transformations et créer les fichiers de données organisées dans un lac de données. Vous devez utiliser une couche or pour les données organisées afin de les séparer logiquement des données brutes stockées dans la couche bronze. La séparation des données en couches simplifie également le paramétrage d’autorisations d’accès utilisateur différentes.

Utilisez un lac de données pour transformer et organiser les données quand :

• Vous vous attendez à ce qu’il y a ait plusieurs modèles de données Power BI dédiés à la création de rapports (justifiant ainsi la création d’une couche argent intermédiaire).
• Vous devez prendre en charge plusieurs créateurs de contenu en libre-service qui ont besoin d’accéder aux données d’audit au niveau du locataire.
• Vous avez déjà des outils et des processus, et voulez les utiliser pour transformer et charger les données.
• Vous voulez réduire la préparation de données (potentiellement dupliquée) dans un ou plusieurs modèles de données Power BI.

Modèle de données Power BI

Vous pourrez peut-être faire tout le travail de transformation dans Power BI. Utilisez Power Query pour accéder aux données et les transformer de leur état brut en format organisé.

Utilisez un modèle de données Power BI quand :

• Vous voulez simplifier l’architecture de bout en bout et charger le modèle de données directement à partir des données brutes. (L’actualisation incrémentielle peut aider à réduire les durées d’actualisation.)
• Vous préférez effectuer tout le travail de transformation pendant le chargement du modèle de données.
• Vous comptez utiliser un seul modèle de données centralisé pour les données d’audit au niveau du locataire. Tous les rapports (ou les autres modèles de données) peuvent utiliser le modèle sémantique Power BI centralisé comme source.
• Vous voulez fournir un accès utilisateur uniquement sur le modèle sémantique Power BI centralisé (et non sur l’une des données sources).

Conseil

Quand vous créez les données organisées, configurez-les de manière à pouvoir facilement réexécuter le processus pour des plages de dates antérieures. Par exemple, vous découvrez qu’un nouvel attribut est apparu dans les journaux d’audit il y a trois mois, et voulez pouvoir l’analyser depuis son apparition. La possibilité de recharger l’historique des données organisées est une des raisons pour lesquelles il est important de stocker les données brutes dans leur état d’origine (décrit plus haut dans cet article).

Pour plus d’informations sur les tables de dimension et les tables de faits que vous pouvez intégrer à votre schéma en étoile, consultez Créer un modèle de données plus loin dans cet article.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier la création des données organisées :

• Déterminer où les transformations doivent être effectuées : déterminez où effectuer en amont le travail de transformation et où il s’intègre dans votre plan pour l’ensemble de l’architecture.
• Déterminer l’outil à utiliser pour transformer les données en schéma d’étoile : confirmez les outils et services utilisés pour transformer les données brutes en données organisées.
• Déterminer où les données organisées doivent être stockées : déterminez le meilleur choix pour stocker les données brutes qui ont été transformées dans un format de schéma en étoile. Déterminez si une couche argent intermédiaire est utile dans l’architecture de bout en bout.
• Créer une convention de nommage : déterminez la convention de nommage à utiliser pour les fichiers et dossiers des données organisées (le cas échéant). Ajoutez ces détails dans votre documentation technique.
• Réfléchir au fonctionnement de la sécurité des données organisées : pendant la conception de l’emplacement de stockage des données organisées, déterminez qui doit accéder aux données et comment attribuer la sécurité.

Décisions relatives à la source de données

À ce stade, vous devez avoir une idée claire des exigences, des données nécessaires et des autorisations. Vous avez pris des décisions d’ordre technique. Vous devez maintenant choisir l’approche à suivre pour obtenir certains types de données.

Accéder aux données d’activité utilisateur

Les données d’activité utilisateur Power BI, parfois appelées journal d’activité ou journaux d’audit, comprennent une multitude d’informations pour vous aider à comprendre ce qui se passe dans votre locataire Power BI. Pour plus d’informations sur l’identification des données dont vous avez besoin, consultez Données d’activité utilisateur plus haut dans cet article.

Power BI intègre ses journaux au journal d’audit unifié Microsoft Purview (anciennement le journal d’audit unifié Microsoft 365). Cette intégration est un avantage, car chaque service au sein de Microsoft 365 n’a pas besoin d’implémenter sa propre journalisation. Il est activé par défaut.

Important

Si vous n’avez pas déjà commencé à extraire les données d’activité utilisateur, faites-en une priorité urgente. Les données d’activité utilisateur sont disponibles sur les 30 ou 90 derniers jours (selon la source). Même si vous n’êtes pas prêt pour une analytique approfondie, vous devez commencer à extraire et stocker les données le plus tôt possible. De cette façon, vous construisez un historique précieux pour l’analyse.

Vous avez plusieurs options pour récupérer les données d’activité utilisateur.

Technique	Description	Jours d’historique disponibles par défaut	Bon choix pour les processus d’audit manuels	Bon choix pour les processus d’audit automatisés	Bon choix pour configurer des alertes	Bon choix pour une prise en main rapide
Manuel (interface utilisateur)	Portail de conformité Microsoft Purview	90
Manuel (interface utilisateur)	Defender for Cloud Apps	30
Par programme	Journal d’activité Power BI (API ou applet de commande PowerShell)	30
Par programme	API Activité de gestion Office 365	7
Par programme	Microsoft Sentinel (Azure Monitor)	30

Le reste de cette section présente chacune des techniques indiquées dans le tableau.

Portail de conformité Microsoft Purview

L’outil de recherche d’audit du portail de conformité Microsoft Purview (anciennement centre de conformité Microsoft 365) est un endroit pratique pour voir les activités et les alertes. Avec cet outil, vous n’avez pas besoin de créer un script pour extraire et télécharger les données. Vous pouvez choisir une charge de travail Power BI pour voir tous les enregistrements du journal d’audit sur une période donnée. Vous pouvez également affiner les résultats en sélectionnant des activités et des utilisateurs spécifiques. Par exemple, un responsable vous demande de déterminer qui a supprimé un espace de travail plus tôt dans la journée afin de pouvoir rapidement contacter la personne pour discuter de la situation.

Les 90 derniers jours d’historique sont disponibles avec Audit (Standard). Avec Audit (Premium), la conservation à long terme vous permet (éventuellement) de conserver les journaux d’audit plus longtemps. Comme la conservation à long terme s’applique uniquement aux utilisateurs E5 sous licence, elle exclut les enregistrements d’audit des utilisateurs qui n’ont pas de licence E5 et des utilisateurs invités. Par conséquent, nous vous recommandons de vous fier uniquement à l’historique par défaut de 90 jours pour que toutes les activités soient capturées.

Il y a des exigences de licence pour pouvoir accéder aux journaux d’audit dans le portail de conformité Microsoft Purview. Des autorisations Exchange Online élevées sont également nécessaires pour accéder aux journaux d’audit.

Conseil

Par défaut, les administrateurs Power BI n’ont pas l’autorisation d’accéder à la recherche dans le journal d’audit unifié du portail de conformité Microsoft Purview. Comme il contient des données destinées à de nombreux services Microsoft 365, c’est un rôle avec des privilèges élevés. Dans la plupart des organisations, ces autorisations sont réservées à un petit nombre d’administrateurs informatiques. D’autres options sont disponibles pour les administrateurs Power BI, elles sont décrites plus loin dans cette section.

L’interface utilisateur dans le portail de conformité Microsoft Purview est utile pour les processus d’audit manuels et les investigations occasionnelles d’activités utilisateur.

Defender for Cloud Apps

Le portail dans Defender for Cloud Apps est un endroit pratique pour voir les activités et les alertes sans avoir besoin de créer un script pour extraire et télécharger les données. Il vous permet également de voir les données du journal d’activité Power BI et les connexions utilisateur.

Defender for Cloud Apps a une interface utilisateur permettant de consulter les journaux d’activité de différents services cloud, notamment Power BI, et d’y faire des recherches. Il affiche les mêmes événements de journal que ceux du journal d’audit unifié Microsoft Purview, en plus d’autres événements comme l’activité de connexion des utilisateurs à partir de Microsoft Entra ID.

De la même façon que le portail de conformité Microsoft Purview (décrit dans la section précédente), Defender for Cloud Apps a une interface utilisateur qui autorise les recherches. Toutefois, les options de filtre sont différentes. En plus de l’historique standard de 30 jours, vous pouvez utiliser Defender for Cloud Apps pour voir jusqu’à six mois d’historique du journal d’activité (par incréments de sept jours).

Il y a des exigences de licence pour accéder à Defender for Cloud Apps. Des autorisations distinctes sont également nécessaires.

Conseil

Par défaut, les administrateurs Power BI n’ont pas l’autorisation d’accéder à Defender for Cloud Apps. Il y a un rôle Power BI dans Defender for Cloud Apps. L’ajout d’administrateurs Power BI à ce rôle est un bon moyen d’accorder l’accès à un ensemble limité de données.

L’interface utilisateur dans Defender for Cloud Apps est utile pour les processus d’audit manuels et les investigations ponctuelles d’activités utilisateur.

Journal d’activité de Power BI

Le journal d’activité Power BI vient du journal d’audit unifié. Il contient uniquement les activités utilisateur liées au service Power BI.

Conseil

Pour les organisations qui prévoient d’extraire les activités utilisateur, nous recommandons de commencer par le journal d’activité Power BI. C’est la source la plus simple à laquelle accéder programmatiquement.

Vous avez deux options pour accéder au journal d’activité Power BI.

• Appeler l’API REST Get Activity Events en utilisant l’outil de votre choix.
• Utiliser l’applet de commande PowerShell Get-PowerBIActivityEvent. Elle est disponible dans le module Admin de gestion Power BI.

Pour plus d’informations sur l’option à utiliser, consultez Choisir des API ou des applets de commande PowerShell plus haut dans cet article.

Conseil

Pour obtenir des exemples d’accès au journal d’activité Power BI avec PowerShell, consultez Accéder au journal d’activité Power BI.

Les données du journal d’activité Power BI sont disponibles pour tous les administrateurs Power BI, les administrateurs Power Platform et les administrateurs généraux. Les données sont accessibles à partir du journal d’audit unifié, disponible pour certains rôles Exchange Online. Pour plus d’informations, consultez Suivre les activités utilisateur dans Power BI.

Nous vous recommandons d’utiliser le journal d’activité Power BI si votre intention est de récupérer uniquement les enregistrements du journal d’audit Power BI.

Notes

Dans les données du journal d’audit, les espaces de travail sont appelés dossiers. Dans l’API REST Power BI, les espaces de travail sont appelés groupes.

API Activité de gestion Office 365

Vous pouvez extraire des données du journal d’audit unifié pour d’autres services, comme SharePoint Online, Teams, Exchange Online, Dynamics 365 et Power BI. Si votre objectif est d’implémenter une solution d’audit et de monitoring pour plusieurs services, nous vous recommandons d’utiliser l’API Activité de gestion Office 365. Comme cette API renvoie des données de nombreux services, elle est appelée API d’audit unifiée (ou journal d’audit unifié). Il s’agit d’une des API de gestion Office 365.

Avant de créer une solution, nous vous recommandons de contacter votre service informatique pour déterminer s’il existe déjà des enregistrements d’audit Power BI disponibles. Il y a peut-être déjà un processus qui extrait et stocke les données. Et vous avez peut-être la possibilité d’obtenir l’autorisation d’accéder à ces données au lieu de créer une solution.

Vous avez deux façons d’accéder aux données.

• Appeler directement l’API Activité de gestion Office 365 avec l’outil de votre choix. Par défaut, l’API renvoie 24 heures de données. Vous pouvez récupérer un maximum de sept jours d’historique.
• Utiliser l’applet de commande PowerShell Search-UnifiedAuditLog. C’est une applet de commande PowerShell Exchange Online. Vous pouvez récupérer au maximum 90 jours d’historique.

Important

L’applet de commande Search-UnifiedAuditLog n’est pas très scalable et vous devez implémenter une stratégie de bouclage pour dépasser sa limite de 5 000 lignes. Pour ces raisons, elle convient aux requêtes occasionnelles ou aux petites organisations qui ont une faible activité. Si vous avez uniquement besoin de données Power BI, nous vous recommandons d’utiliser l’applet de commande Get-PowerBIActivityEvent à la place.

En général, la prise en main de l’API Activité de gestion Office 365 est plus difficile que l’utilisation du journal d’activité Power BI (décrit précédemment). En effet, l’API renvoie des blobs de contenu, et chaque blob de contenu contient des enregistrements d’audit individuels. Pour les grandes organisations, il peut y avoir des milliers de blobs de contenu par jour. Comme les clients et les applications tierces utilisent beaucoup cette API, Microsoft implémente une limitation pour que leur utilisation du service n’affecte pas les autres utilisateurs (connu comme le problème du voisin bruyant). Par conséquent, la récupération de grands volumes d’historique peut être un défi pour les grandes organisations. Pour plus d’informations, consultez cet article de résolution de problèmes.

Pour utiliser cette API, vous devez vous authentifier avec un principal de service qui a reçu l’autorisation de récupérer des données à partir de l’API Activité de gestion Office 365.

Conseil

Par défaut, les administrateurs Power BI n’ont pas l’autorisation d’accéder à l’API Activité de gestion Office 365. Comme elle contient des données destinées à de nombreux services Microsoft 365, l’accès nécessite des rôles d’audit ou d’administrateur avec des privilèges élevés. Dans la plupart des organisations, ces rôles sont réservés à un petit nombre d’administrateurs informatiques. Le journal d’activité Power BI est destiné aux administrateurs Power BI.

La récupération des données d’audit programmatiquement à partir de l’API Activité de gestion Office 365 est un bon choix si le service informatique doit extraire et stocker les journaux d’audit de différents services (en plus de Power BI).

Microsoft Sentinel

Microsoft Sentinel est un service Azure qui vous permet de collecter, de détecter, d’examiner les incidents et menaces de sécurité et d’y répondre. Vous pouvez configurer Power BI dans Microsoft Sentinel sous forme de connecteur de données. Quand il est connecté, les journaux d’audit (qui contiennent un sous-ensemble des données) sont diffusés en streaming à partir de Power BI vers Azure Log Analytics, qui est une fonctionnalité d’Azure Monitor.

Conseil

Azure Log Analytics est basé sur la même architecture que celle utilisée par les journaux d’événements de modèle sémantique au niveau de l’espace de travail. Pour plus d’informations sur les journaux des événements de modèle sémantique, consultez Audit au niveau des données.

Parce que c’est un service Azure distinct, tout administrateur ou utilisateur souhaitant exécuter des requêtes en Langage de requête Kusto (KQL) doit avoir des autorisations dans Azure Log Analytics (Azure Monitor). S’ils ont l’autorisation, ils peuvent interroger les données d’audit stockées dans la table PowerBIActivity. Toutefois, gardez à l’esprit que, dans la plupart des cas, vous accordez aux utilisateurs un accès aux données organisées dans la couche or plutôt qu’aux données brutes dans la couche bronze.

Vous utilisez KQL pour analyser les événements du journal d’activité stockés dans Azure Log Analytics. Si vous connaissez déjà SQL, il y a de nombreuses similitudes avec KQL.

Vous pouvez accéder aux événements stockés dans Azure Log Analytics de plusieurs façons. Vous pouvez utiliser :

• L’application modèle Log Analytics pour modèles sémantiques Power BI prédéfinie.
• Le connecteur Power BI Desktop pour Azure Data Explorer (Kusto).
• L’expérience de requête web dans Azure Data Explorer.
• Tout outil de requête capable d’envoyer des requêtes KQL.

Attention

N’oubliez pas que seul un sous-ensemble des données du journal d’activité Power BI est stocké dans Azure Monitor. Si vous voulez effectuer une analyse complète de l’utilisation et de l’adoption de Power BI dans l’organisation, nous vous recommandons d’utiliser d’autres options (décrites plus haut dans cette section) pour récupérer les données d’activité.

La période d’historique que vous pouvez récupérer dépend de la stratégie de conservation des données de l’espace de travail Azure Log Analytics. Tenez compte du coût et de l’accès aux données brutes quand vous choisissez la quantité de données à conserver.

Microsoft Sentinel et Azure Monitor sont de bonnes options si le service informatique a déjà investi dans Microsoft Sentinel, que le niveau de détail capturé répond à vos besoins et que des activités comme la détection des menaces sont prioritaires. Toutefois, parce que Microsoft Sentinel ne capture pas toutes les données d’activité Power BI, il ne prend pas en charge l’analyse complète de l’utilisation et de l’adoption de Power BI.

Considérations sur les données d’activité utilisateur

Voici quelques considérations pour vous aider à choisir votre source de données d’activité utilisateur.

• Le processus d’audit est-il manuel ou automatisé ? Les options d’interface utilisateur fonctionnent bien pour les processus d’audit manuels et les requêtes ponctuelles, en particulier quand vous devez investiguer une activité spécifique. Un processus d’audit automatisé qui extrait les données d’activité utilisateur selon une planification est également nécessaire pour prendre en charge l’analyse des données historiques.
• À quelle fréquence avez-vous besoin des données d’activité utilisateur ? Pour les processus d’audit automatisés, vous devez commencer à extraire les données au moins un jour avant la date actuelle, en utilisant le temps universel coordonné (UTC) plutôt que votre heure locale. Par exemple, si votre processus s’exécute le vendredi matin (heure UTC), vous devez extraire les données du mercredi. Il y a plusieurs raisons pour lesquelles vous devez extraire les données avec une latence d’un jour.
  • Vos fichiers sont plus simples à utiliser si vous extrayez toujours 24 heures à la fois, ce qui évite les résultats de jour partiels.
  • Vous réduisez le risque de manquer certains événements d’audit. En règle générale, les événements d’audit arrivent au bout de 30 minutes. Parfois, certains événements peuvent prendre jusqu’à 24 heures pour arriver dans le journal d’audit unifié.
• Avez-vous besoin d’autres données que les données Power BI ? Réfléchissez à la façon la plus efficace d’accéder aux données dont vous avez besoin.
  • Si vous avez uniquement besoin de données d’activité utilisateur Power BI, utilisez le journal d’activité Power BI.
  • Si vous avez besoin de journaux d’audit de plusieurs services, utilisez l’API Activité de gestion Office 365 pour accéder au journal d’audit unifié.
• Qui développe la solution ? Prévoyez du temps pour créer la solution. La production d’un script prêt pour la production peut nécessiter beaucoup d’efforts.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier l’accès aux données d’activité utilisateur :

• Clarifier l’étendue des besoins : déterminez si vous devez accéder uniquement aux enregistrements d’audit Power BI ou aux données d’audit de plusieurs services.
• Consulter le service informatique : vérifiez si le service informatique extrait actuellement des journaux d’audit et si vous pouvez obtenir l’accès aux données brutes, ce qui vous éviterait de créer une solution.
• Choisir une source de données : déterminez la meilleure source à utiliser pour accéder aux données d’activité utilisateur.
• Effectuer une preuve de concept : prévoyez d’effectuer une petite preuve de concept technique. Utilisez-la pour valider vos décisions concernant la création de la solution finale.
• Suivre les besoins supplémentaires en matière de données : vous pouvez mettre en corrélation les données du journal d’activité avec d’autres sources pour améliorer la valeur des données. Faites un suivi de ces opportunités quand elles se présentent pour les ajouter à l’étendue de votre projet.

Accéder aux données d’inventaire du locataire

Un inventaire de locataire est un composant inestimable et nécessaire dans une solution d’audit et de monitoring mature. Il vous aide à comprendre les espaces de travail et le contenu (modèles sémantiques, rapports et autres éléments) qui existent dans Power BI, et complète de manière optimale les données d’activité utilisateur (décrites dans la section précédente). Pour plus d’informations sur l’identification des données dont vous avez besoin, consultez Inventaire du locataire plus haut dans cet article.

Les activités utilisateur (décrites précédemment) sont des événements audités, c’est-à-dire un enregistrement des actions effectuées par un utilisateur à une date et une heure spécifiques. L’inventaire de locataire est différent. L’inventaire de locataire est un instantané à un moment donné. Il décrit l’état actuel de tous les éléments publiés dans le service Power BI au moment où vous les avez extraits.

Notes

La documentation de l’API REST Power BI appelle les éléments publiés des artefacts.

Conseil

De nombreuses organisations trouvent utile d’extraire l’inventaire de locataire chaque jour à la même heure.

Pour analyser correctement ce qui se passe dans votre locataire Power BI, vous avez besoin des données d’activité utilisateur et de l’inventaire de locataire. La combinaison des deux vous permet de comprendre la quantité de contenu que vous avez et où il se trouve. Elle vous permet également de trouver le contenu inutilisé ou sous-utilisé (car aucun événement pour ce type de contenu n’apparaît dans le journal d’activité). L’inventaire de locataire vous permet également de compiler la liste des noms actuels de tous les éléments, ce qui est utile quand les noms des éléments changent.

Pour plus d’informations sur la valeur de l’inventaire des locataires, consultez Inventaire des locataires plus haut dans cet article.

Conseil

Vous pouvez utiliser l’API Get Unused Artifacts as Admin pour rechercher les éléments qui n’ont pas d’activité utilisateur dans les 30 derniers jours. Toutefois, vous ne pouvez pas personnaliser cet intervalle. Par exemple, si vous avez du contenu critique qui est utilisé seulement tous les trimestres, en combinant votre inventaire de locataire et les données d’activité utilisateur, vous pouvez trouver les éléments inutilisés de plusieurs manières personnalisables.

Vous pouvez obtenir les données d’inventaire de locataire de deux manières différentes.

Technique	Description	Convient plus à	Bon choix pour les processus d’audit manuels	Bon choix pour les processus d’audit automatisés
Par programme	L’API Get Groups as Admin ou l’applet de commande PowerShell Get-PowerBIWorkspace peuvent fournir la liste des espaces de travail de l’ensemble du locataire. Vous pouvez aussi inclure des éléments individuels (comme des modèles sémantiques et des rapports) pour chaque espace de travail.	Petites organisations ou faible volume de données
Par programme	Un ensemble d’API d’administration asynchrones, collectivement appelées API d’analyse des métadonnées ou API d’analyseur, peut renvoyer une liste d’espaces de travail et d’éléments individuels. Vous pouvez également inclure des métadonnées détaillées (comme des tables, des colonnes et des expressions de mesure).	Organisations qui ont un volume de données élevé et/ou ont besoin d’obtenir des résultats détaillés

Le reste de cette section présente chacune des techniques indiquées dans le tableau.

API de groupes ou applet de commande d’espaces de travail

Pour récupérer une liste d’espaces de travail, vous pouvez utiliser diverses API REST, comme l’API Get Groups as Admin (avec l’outil de votre choix). Les résultats comprennent des métadonnées supplémentaires comme la description et si l’espace de travail est stocké dans une capacité Premium.

Notes

Les noms d’API utilisent le terme group pour désigner un espace de travail. Ce terme vient du modèle de sécurité Power BI d’origine, qui s’appuyait sur des groupes Microsoft 365. Bien que le modèle de sécurité Power BI ait considérablement évolué au fil des ans, les noms d’API existants sont restés les mêmes pour éviter de casser les solutions existantes.

L’API REST Get Groups as Admin comprend le paramètre utile $expand. Ce paramètre vous permet de développer éventuellement les résultats pour ajouter la liste des éléments publiés dans l’espace de travail (comme les modèles sémantiques et les rapports). Vous pouvez également passer le type de données users au paramètre $expand pour ajouter les utilisateurs qui sont attribués à un rôle d’espace de travail.

Vous pouvez aussi utiliser l’applet de commande PowerShell Get-PowerBIWorkspace. Elle vient du module Workspaces de gestion Power BI. Quand vous définissez le paramètre -Scope sur organization, il fonctionne comme l’API Get Groups as Admin. L’applet de commande accepte également le paramètre -Include (qui est l’équivalent du paramètre $expand dans l’API REST) pour ajouter les éléments publiés dans l’espace de travail (comme les modèles sémantiques et les rapports).

Conseil

En passant des paramètres, vous pouvez utiliser l’applet de commande de différentes manières. Cette section se concentre sur la récupération d’un inventaire à l’échelle du locataire. Pour plus d’informations sur l’utilisation du paramètre -Scope, consultez Choisir une API utilisateur ou une API d’administration plus haut dans cet article.

Pour vous aider à choisir l’option à utiliser, consultez Choisir des API ou des applets de commande PowerShell plus haut dans cet article.

L’API REST Get Groups as Admin ou l’applet de commande PowerShell Get-PowerBIWorkspace conviennent mieux aux processus d’audit manuels et aux investigations ponctuelles. Les grandes organisations avec un volume de données élevé trouvent généralement ces options difficiles à utiliser. L’API REST et l’applet de commande extraient toujours un ensemble complet de données, elles peuvent donc prendre beaucoup de temps pour s’exécuter. Par conséquent, les grandes organisations peuvent être limitées dans le nombre de demandes autorisées par heure (c’est une limitation appliquée pour protéger l’intégrité du service). Les API d’analyse des métadonnées (décrites ci-dessous) fournissent une alternative plus fiable et scalable.

API d’analyse des métadonnées

Les API d’analyse des métadonnées, souvent appelées API d’analyseur, sont un ensemble d’API qui renvoient une liste d’espaces de travail et leurs éléments Power BI (modèles sémantiques, rapports et autres éléments). D’un point de vue conceptuel, elles fournissent les mêmes données (et plus) que les API de groupes ou l’applet de commande d’espace de travail (décrites dans la section précédente). Toutefois, la méthode que vous utilisez pour récupérer les données est différente et mieux adaptée à l’extraction de l’inventaire du locataire.

Notes

Notez comment certaines personnes utilisent le terme API d’analyseur ou l’expression analyse du locataire. Elles utilisent souvent ces termes pour désigner la compilation d’un inventaire de locataire, en le distinguant des événements d’activité utilisateur. Certaines personnes peuvent, ou non, faire littéralement référence à l’utilisation des API d’analyse de métadonnées.

Il y a deux grandes raisons pour lesquelles vous devez utiliser les API d’analyse des métadonnées au lieu de l’API REST Get Groups as Admin ou de l’applet de commande Get-PowerBIWorkspace (décrites précédemment).

• Extraction de données incrémentielle : les API d’analyseur extraient uniquement les données qui ont changé depuis leur dernière exécution. À l’inverse, l’API REST Get Groups as Admin et l’applet de commande Get-PowerBIWorkspace sont des opérations synchrones qui extraient l’ensemble des données chaque fois qu’elles s’exécutent.
• Niveau de détail plus précis : les API d’analyseur peuvent récupérer des détails granulaires (comme des tables, des colonnes et des expressions de mesure), à condition que les deux paramètres de locataire pour les métadonnées détaillées en donnent l’autorisation. À l’inverse, le plus petit niveau de détail disponible avec l’API REST Get Groups as Admin et l’applet de commande Get-PowerBIWorkspace est le type d’élément (par exemple, la liste des rapports dans un espace de travail).

L’utilisation des API d’analyseur implique plus d’efforts, car vous devez appeler une série d’API. Par ailleurs, elles s’exécutent dans un processus asynchrone. Un processus asynchrone s’exécute en arrière-plan et vous n’avez pas besoin d’attendre qu’il se termine. Vous pouvez avoir besoin de collaborer avec le service informatique ou un développeur au moment de créer un script prêt pour la production associé à une planification.

Voici la séquence d’étapes que votre processus doit suivre avec les API d’analyseur.

1. Se connecter : connectez-vous au service Power BI avec un compte d’administrateur Power BI ou un principal de service autorisé à exécuter des API d’administration. Pour plus d’informations, consultez Déterminer la méthode d’authentification plus haut dans cet article.
2. Obtenir les ID d’espace de travail : envoyez une demande pour récupérer la liste des ID d’espace de travail. La première fois qu’elle est exécutée, vous n’avez pas de date de modification et obtenez la liste complète des espaces de travail. En règle générale, vous passez la date de modification pour récupérer uniquement les espaces de travail qui ont changé depuis ce point dans le temps. La date de modification doit être dans les 30 derniers jours.
3. Lancer une analyse des métadonnées : lancez un appel pour demander une analyse des informations d’espace de travail en passant les ID d’espace de travail récupérés à l’étape 2. Notez qu’il s’agit d’une API POST (et non une API GET, qui est plus courante pour récupérer les données d’audit). Une API POST est une requête HTTP qui crée ou écrit des données pour une ressource spécifiée. Cette requête spécifie le niveau de détail à extraire, comme les détails de la source de données, le schéma du modèle sémantique, les expressions de modèle sémantique ou les utilisateurs. Quand la requête est envoyée, l’API renvoie un ID d’analyse. Elle renvoie également la date et l’heure de l’analyse, que vous devez enregistrer comme date de l’instantané.
4. Vérifier l’état de l’analyse : utilisez l’ID d’analyse obtenu à l’étape 3 pour obtenir l’état de l’analyse. Vous devez peut-être appeler cette API plusieurs fois. Si l’état renvoyé est Réussite,vous pouvez passer à l’étape suivante. La durée de l’analyse dépend de la quantité de données que vous demandez.
5. Obtenir les résultats : utilisez l’ID d’analyse obtenu à l’étape 3 pour obtenir le résultat de l’analyse et extraire les données. Vous devez effectuer cette étape dans les 24 heures suivant l’étape 4. N’oubliez pas que l’horodatage de l’instantané doit être mis en corrélation avec l’étape 3 plutôt que l’étape 5 (en cas de retard important). De cette façon, vous avez un horodatage d’instantané exact. Enregistrez les résultats dans votre emplacement de stockage de données préféré. Comme déjà décrit dans cet article, nous vous recommandons de stocker les données brutes dans leur état d’origine.
6. Préparer le processus suivant : enregistrez l’horodatage de l’analyse de l’étape 3 pour pouvoir l’utiliser à l’étape 2 la prochaine fois que vous exécutez le processus. De cette façon, vous extrayez uniquement les données qui ont changé depuis ce point dans le temps. Par la suite, toutes les extractions de données sont des changements incrémentiels plutôt que des instantanés complets.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier l’accès aux données d’inventaire de locataire :

• Confirmer les exigences : clarifiez les besoins pour compiler un inventaire de locataire et les exigences analytiques pour les données.
• Choisir la fréquence d’extraction de l’inventaire de locataire : confirmez la fréquence à laquelle vous avez besoin d’un nouvel inventaire de locataire (par exemple, toutes les semaines).
• Choisir comment extraire l’inventaire de locataire : confirmez la méthode à utiliser pour obtenir les données d’inventaire de locataire (API, applet de commande ou API d’analyse des métadonnées).
• Effectuer une preuve de concept : prévoyez d’effectuer une petite preuve de concept technique. Utilisez-la pour valider vos décisions concernant la création de la solution finale.

Accéder aux données d’utilisateurs et de groupes

En plus des informations d’identification (comme une adresse e-mail) comprises dans les données d’activité utilisateur, il est utile de récupérer d’autres informations comme la localisation ou les détails de l’organisation. Vous pouvez utiliser Microsoft Graph pour récupérer des données sur les utilisateurs, les groupes, les principaux de service et les licences. Microsoft Graph comprend un ensemble d’API et de bibliothèques de client qui vous permettent de récupérer des données d’audit d’une grande variété de services.

Voici quelques détails auxquels vous avez accès concernant les objets Microsoft Entra.

• Utilisateur : identité qui existe dans Microsoft Entra ID en tant que compte professionnel, scolaire ou Microsoft. Le terme utilisateur de domaine est souvent utilisé pour décrire les utilisateurs de l’organisation, mais le terme formel est nom d’utilisateur principal (UPN). Un UPN a généralement la même valeur que l’adresse e-mail de l’utilisateur (bien que si une adresse e-mail change, l’UPN ne change pas, car il est immuable). Il y a également un ID Microsoft Graph unique pour chaque utilisateur. Souvent, un compte d’utilisateur est associé à une seule personne. Certaines organisations créent des utilisateurs qui sont des comptes de service utilisés pour les activités automatisées ou les tâches d’administration.
• Principal de service : autre type d’identité, provisionné quand vous créez une inscription d’application. Un principal de service est destiné aux activités automatisées sans assistance. Pour plus d’informations, consultez Déterminer la méthode d’authentification plus haut dans cet article.
• Groupe : collection d’utilisateurs et de principaux de service. Il y a plusieurs types de groupe que vous pouvez utiliser pour simplifier la gestion des autorisations. Pour plus d’informations, consultez Stratégie d’utilisation des groupes.

Notes

Quand cet article fait référence aux utilisateurs et groupes, cette expression comprend également les principaux de service. C’est une expression plus courte utilisée pour plus de concision.

Les données d’utilisateurs et de groupes que vous récupérez sont un instantané qui décrit l’état actuel à un point dans le temps.

Conseil

Pour plus d’informations sur les utilisateurs, les principaux de service et les groupes, consultez Intégration à Microsoft Entra ID.

Attributs analytiques

Pour l’audit au niveau du locataire Power BI, vous pouvez extraire et stocker les attributs suivants à partir de Microsoft Graph.

• Nom complet des utilisateurs : de nombreuses sources de données comprennent uniquement l’adresse e-mail de l’utilisateur qui a effectué une activité ou qui est attribué à un rôle. Utilisez cet attribut si vous voulez afficher le nom complet (nom d’affichage) dans les rapports analytiques. L’utilisation du nom complet rend les rapports plus conviviaux.
• Autres propriétés utilisateur : d’autres attributs descriptifs sur les utilisateurs seront sans doute disponibles dans Microsoft Entra ID. Les attributs de profil utilisateur intégrés qui ont une valeur analytique sont, par exemple, le poste, le service, le responsable, la région et la localisation du bureau.
• Membres d’un groupe de sécurité : la plupart des sources de données fournissent le nom d’un groupe (par exemple, le journal d’activité Power BI enregistre chaque attribution d’un groupe de sécurité à un rôle d’espace de travail). La récupération de l’appartenance au groupe améliore votre capacité à analyser entièrement ce qu’un utilisateur fait ou ce à quoi il a accès.
• Licences utilisateur : il est utile d’analyser les licences utilisateur (gratuites, Power BI Pro ou Power BI Premium par utilisateur) qui sont attribuées aux utilisateurs. Ces données peuvent vous aider à identifier les utilisateurs qui n’utilisent pas leur licence. Elles vous permettent également d’analyser tous les utilisateurs (utilisateurs distincts avec une licence) par rapport aux utilisateurs actifs (avec des activités récentes). Si vous voulez ajouter des licences ou développer vos licences Power BI Premium, nous vous recommandons d’analyser les données de licence utilisateur avec les données d’activité utilisateur pour effectuer une analyse des coûts.
• Membres des rôles Administrateur : vous pouvez compiler la liste de vos administrateurs Power BI (y compris les administrateurs Power Platform et les administrateurs généraux).

Pour obtenir la référence officielle des informations de licence Power BI que vous pouvez trouver dans les données d’audit de Microsoft Graph, consultez Noms de produit et identificateurs de plan de service pour les licences.

Conseil

La récupération des membres de groupes peut être l’un des aspects les plus difficiles de l’obtention des données d’audit. Vous devez faire une recherche transitive pour aplatir tous les membres imbriqués et les groupes imbriqués. Vous pouvez faire une recherche transitive pour les membres de groupe. Ce type de recherche est particulièrement difficile quand vous avez des milliers de groupes dans votre organisation. Dans ce cas, réfléchissez à d’autres alternatives pour récupérer les données. Par exemple, vous pouvez extraire tous les groupes et les membres de groupe à partir de Microsoft Graph. Toutefois, ce ne sera peut-être pas pratique quand seuls quelques groupes seront utilisés pour la sécurité Power BI. Vous pouvez aussi précréer une liste de référence des groupes qui sont utilisés par tel ou tel type de sécurité Power BI (rôles d’espace de travail, autorisations d’application, partage par élément, sécurité au niveau des lignes, etc.). Vous pouvez ensuite parcourir la liste de référence pour récupérer les membres de groupe à partir de Microsoft Graph.

Voici d’autres attributs que vous pouvez extraire et stocker.

• Type d’utilisateur : les utilisateurs sont des membres ou des invités. Le plus souvent, les membres sont des utilisateurs internes et les invités sont des utilisateurs externes (B2B). Le stockage du type d’utilisateur est utile si vous devez analyser les activités des utilisateurs externes.
• Changements de rôle : quand vous faites un audit de sécurité, il est utile de comprendre quand un utilisateur change de rôle dans l’organisation (par exemple, quand il est transféré dans un autre service). De cette façon, vous pouvez vérifier si ses paramètres de sécurité Power BI ont été mis à jour ou pas encore.
• Utilisateurs désactivés : quand un utilisateur quitte l’organisation, un administrateur désactive généralement son compte. Vous pouvez créer un processus pour vérifier si les utilisateurs désactivés sont des administrateurs d’espace de travail ou des propriétaires de modèle sémantique.

Conseil

Le journal d’activité Power BI comprend un événement qui enregistre quand un utilisateur s’inscrit à une licence d’essai. Vous pouvez combiner cet événement avec les données de licence utilisateur (provenant de Microsoft Entra ID) pour produire une image complète.

Récupérer des données d’utilisateurs et de groupes

Vous pouvez récupérer des données sur les utilisateurs et les groupes de différentes manières.

Technique	Description	Bon choix pour les processus d’audit manuels	Bon choix pour les processus d’audit automatisés
Manuel	Explorateur graphique
Par programme	API et SDK Microsoft Graph
Par programme	Module az PowerShell

Le reste de cette section présente chacune des techniques indiquées dans le tableau. D’autres techniques, qui sont dépréciées et ne doivent pas être utilisées pour les nouvelles solutions, sont décrites à la fin de cette section.

Notes

Soyez prudent quand vous lisez des informations en ligne, car de nombreux noms d’outils se ressemblent. Certains outils de l’écosystème Microsoft comprennent le terme Graph dans leur nom, comme Azure Resource Graph, GraphQL et l’API Microsoft Security Graph. Ces outils ne sont pas liés à Microsoft Graph, et ne sont pas décrits dans cet article.

Afficheur Microsoft Graph

Microsoft Graph Explorer est un outil de développement qui vous permet d’en savoir plus sur les API Microsoft Graph. C’est un moyen simple de se lancer, car il ne nécessite aucun autre outil ni configuration sur votre machine. Vous pouvez vous connecter pour récupérer des données de votre locataire ou récupérer des exemples de données à partir d’un locataire par défaut.

Vous pouvez utiliser Graph Explorer pour :

• Envoyer manuellement une demande à une API Microsoft Graph pour vérifier si elle renvoie les informations souhaitées.
• Découvrir comment construire l’URL, les en-têtes et le corps avant d’écrire un script.
• Vérifier les données de manière informelle.
• Déterminer les autorisations nécessaire pour chaque API. Vous pouvez également fournir un consentement pour les nouvelles autorisations.
• Obtenir des extraits de code pour créer des scripts.

Utilisez ce lien pour ouvrir Graph Explorer.

API et SDK Microsoft Graph

Utilisez les API Microsoft Graph pour récupérer les données d’utilisateurs et de groupes. Vous pouvez également l’utiliser pour récupérer des données auprès de services comme Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook, etc.

Les SDK Microsoft Graph servent de wrapper d’API par-dessus les API Microsoft Graph sous-jacentes. Un SDK est un kit de développement logiciel qui regroupe des outils et des fonctionnalités. Les SDK Microsoft Graph exposent l’ensemble des API Microsoft Graph.

Vous pouvez choisir d’envoyer des demandes directement aux API. Vous pouvez aussi ajouter une couche de simplification en utilisant votre langage préféré et un des SDK. Pour plus d’informations, consultez Choisir des API ou des applets de commande PowerShell plus haut dans cet article.

Les SDK Microsoft Graph prennent en charge plusieurs langages, et vous avez aussi les modules Microsoft Graph PowerShell. D’autres SDK sont disponibles pour Python, C# et d’autres langages.

Important

Le module Microsoft Graph PowerShell remplace les modules Azure AD PowerShell et MSOnline (MSOL), qui sont tous deux dépréciés. Vous ne devez pas créer de solutions avec des modules dépréciés. Le module Microsoft Graph PowerShell présente de nombreux avantages et fonctionnalités. Pour plus d’informations, consultez Passer d’Azure AD PowerShell à Microsoft Graph PowerShell.

Vous pouvez installer les module Microsoft Graph PowerShell à partir de PowerShell Gallery. Comme Microsoft Graph fonctionne avec de nombreux services Microsoft 365, il y a de nombreux modules PowerShell à installer.

Pour l’audit au niveau du locataire Power BI, voici les modules PowerShell à installer les plus courants.

• Authentication (pour la connexion)
• Utilisateurs
• Groupes
• Applications (et principaux de service)
• Directory objects (et détails de licence)

Conseil

Microsoft met régulièrement à jour les modules Microsoft Graph PowerShell. Parfois, des modules en préversion sont mis à disposition avant la publication officielle ou sur un point de terminaison bêta. Vous pouvez spécifier la version qui vous intéresse quand vous installez et mettez à jour les modules. Par ailleurs, quand vous consultez la documentation en ligne, notez que le numéro de version actuel est automatiquement ajouté à la fin de l’URL (soyez attentif quand vous enregistrez ou partagez des URL).

Module az PowerShell

Vous pouvez également utiliser le module Az PowerShell pour récupérer des données d’utilisateurs et de groupes. Il est dédié aux ressources Azure.

Important

Le module Az PowerShell remplace les modules AzureRM PowerShell, qui sont dépréciés. Vous ne devez pas créer de solutions avec des modules dépréciés.

Vous pouvez utiliser l’applet de commande Invoke-AzRestMethod si une API n’a pas d’applet de commande correspondante. C’est une approche flexible qui vous permet d’envoyer une demande à une API Microsoft Graph à partir du module Az PowerShell.

À compter d’Az version 7, les applets de commande Az référencent l’API Microsoft Graph. Par conséquent, le module Az sert de wrapper d’API par-dessus Microsoft Graph. Les modules Az ont un sous-ensemble de fonctionnalités contenues dans les API Microsoft Graph et les modules PowerShell. Pour les nouvelles solutions, nous vous recommandons d’utiliser le SDK Microsoft Graph PowerShell.

API et modules dépréciés

Dans certains articles et billets de blog en ligne, vous pouvez trouver des options qui ne sont pas présentées dans cette section. Nous vous recommandons vivement de ne pas créer de solutions (et/ou migrer vos solutions existantes) en utilisant les API ou modules suivants.

• Modules AzureRM PowerShell : dépréciés et bientôt hors service. Ils ont été remplacés par le module Az PowerShell.
• API Azure AD Graph et module Azure AD PowerShell : dépréciés et bientôt hors service. Ce changement est le résultat de la migration d’Azure AD Graph vers Microsoft Graph (notez que Graph apparaît dans les deux noms, mais Microsoft Graph est l’orientation future). Tous les investissements PowerShell futurs seront effectués dans le SDK Microsoft Graph PowerShell. (Azure Active Directory est maintenant appelé Microsoft Entra ID.)
• Module MS Online (MSOL) PowerShell : déprécié et bientôt hors service. Tous les investissements PowerShell futurs seront effectués dans le SDK Microsoft Graph PowerShell.

Attention

Veillez à vérifier l’état des modules ou API dépréciés que vous utilisez actuellement. Pour plus d’informations sur la mise hors service d’AzureRM, consultez cette annonce.

Pour plus d’informations sur Microsoft Entra ID et MSOL, consultez ce billet d’annonce de mise hors service.

Si vous avez des questions ou avez besoin de clarifications sur l’orientation future de l’accès programmatique aux données, contactez votre équipe de compte Microsoft.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier l’accès aux données d’utilisateurs et de groupes :

• Confirmer les exigences : clarifier les besoins en matière de compilation des données d’utilisateurs, de groupes et de licences.
• Hiérarchiser les exigences : confirmez les priorités les plus urgentes pour savoir à quoi vous consacrer en premier.
• Choisir la fréquence d’extraction des données : déterminez la fréquence à laquelle vous avez besoin d’un nouvel instantané des données d’utilisateurs et de groupes (par exemple, chaque semaine ou chaque mois).
• Choisir comment extraire les données avec Microsoft Graph : déterminez la méthode à utiliser pour récupérer les données.
• Effectuer une preuve de concept : prévoyez de faire une petite preuve de concept technique pour extraire les données d’utilisateurs et de groupes. Utilisez-la pour valider vos décisions concernant la création de la solution finale.

Accéder aux données à partir des API REST Power BI

Avec une priorité moins urgente, vous pouvez aussi récupérer d’autres données en utilisant les API REST Power BI.

Par exemple, vous pouvez récupérer des données sur :

• Toutes les applications de l’organisation.
• Tous les modèles sémantiques importés dans l’organisation.
• Tous les pipelines de déploiement dans l’organisation.
• Toutes les capacités Premium dans l’organisation.

Pour un audit de sécurité, vous pouvez identifier :

• Les éléments qui ont été largement partagés avec l’ensemble de l’organisation.
• Les éléments disponibles sur l’Internet public en utilisant la publication sur le web.

Pour plus d’informations sur les autres types d’API, consultez Choisir une API utilisateur ou une API d’administration plus haut dans cet article.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier l’accès aux données à partir des API Power BI :

• Obtenir les exigences : compilez les exigences analytiques à mesure qu’elles se présentent. Faites-en le suivi dans votre backlog.
• Hiérarchiser les exigences : définissez des priorités pour les nouvelles exigences qui se présentent.

Phase 2 : Prérequis et configuration

La deuxième phase de planification et d’implémentation d’une solution d’audit au niveau du locataire se concentre sur les prérequis et la configuration qui doit être effectuée avant de commencer le développement de la solution.

Créer un compte de stockage

À ce stade, vous avez choisi un emplacement où stocker les données brutes et la façon dont vous créez les données organisées. Sur la base de ces décisions, vous êtes maintenant prêt à créer un compte de stockage. Selon les processus de votre organisation, vous devez peut-être envoyer une demande au service informatique.

Comme décrit précédemment, nous vous recommandons d’utiliser une technologie permettant d’écrire les données brutes dans un stockage immuable. Une fois les données écrites, elles ne peuvent être ni changées ni supprimées. Vous pouvez ensuite avoir une totale confiance dans les données brutes, car vous savez que même un administrateur avec un accès ne peut en aucun cas les modifier. En revanche, les données organisées n’ont pas (généralement) besoin d’être stockées dans un stockage immuable. Les données organisées peuvent changer ou être regénérées.

Check-list : voici les décisions et actions clés à prendre en compte pour créer un compte de stockage :

• Créer un compte de stockage : créez un compte de stockage ou envoyez une demande de création de compte de stockage. Dans la mesure du possible, utilisez toujours des paramètres de stockage immuable pour les données brutes.
• Définir les autorisations : déterminez les autorisations à définir pour le compte de stockage.
• Tester l’accès : faites un petit test pour vérifier que vous pouvez lire et écrire dans le compte de stockage.
• Confirmer les responsabilités : veillez à avoir une idée claire de qui gère le compte de stockage de manière continue.

Installer les logiciels et configurer les services

À ce stade, vous avez fait vos choix concernant la technologie à utiliser pour accéder aux données d’audit. Sur la base de ces décisions, vous êtes maintenant prêt à installer les logiciels et à configurer les services.

Configurez l’environnement de développement préféré pour chaque administrateur. L’environnement de développement leur permet d’écrire et de tester des scripts. Visual Studio Code est un outil moderne pour le développement de scripts. C’est une bonne option. Par ailleurs, de nombreuses extensions sont disponibles pour fonctionner avec Visual Studio Code.

Si vous avez pris la décision (décrite précédemment) d’utiliser PowerShell, vous devez installer PowerShell Core et les modules PowerShell nécessaires sur :

• La machine de chaque administrateur/développeur qui écrit ou teste des scripts d’audit.
• Chaque machine virtuelle ou serveur qui exécute les scripts planifiés.
• Chaque service en ligne (par exemple, Azure Functions ou Azure Automation).

Si vous avez choisi d’utiliser des services Azure (comme Azure Functions, Azure Automation, Azure Data Factory ou Azure Synapse Analytics), vous devez également les provisionner et les configurer.

Check-list : voici les décisions et actions clés à prendre en compte pour installer les logiciels et configurer les services :

• Configurer les machines administrateur/développeur : le cas échéant, installez les outils nécessaires utilisés pour le développement.
• Configurer les serveurs : le cas échéant, installez les outils nécessaires sur tous les serveurs ou machines virtuelles présents dans votre architecture.
• Configurer les services Azure : le cas échéant, provisionnez et configurez chaque service Azure. Attribuez des autorisations pour chaque administrateur/développeur qui effectue un travail de développement.

Enregistrer une application Microsoft Entra

À ce stade, vous avez choisi le mode d’authentification. Nous vous recommandons d’inscrire une application Microsoft Entra (principal de service). Communément appelée inscription d’application, elle doit être utilisée pour les opérations sans assistance que vous allez automatiser.

Pour plus d’informations sur la création d’une inscription d’application pour récupérer des données d’audit au niveau du locataire, consultez Activer l’authentification du principal de service pour les API d’administration en lecture seule.

Check-list : au moment d’inscrire une application Microsoft Entra, voici quelques-unes des décisions et des mesures clés à prendre :

• Vérifier s’il y a déjà une inscription d’application existante : vérifiez auprès du service informatique si une inscription d’application existante est disponible dans le but d’exécuter des API d’administration. Si c’est le cas, déterminez si l’inscription d’application existante doit être utilisée ou s’il faut en créer une autre.
• Créer une inscription d’application : créez une inscription d’application selon les besoins. Envisagez d’utiliser un nom d’application tel que PowerBI-AdminAPIs-EntraApp, qui décrit clairement son objectif.
• Créer un secret pour l’inscription d’application : une fois l’inscription d’application créée, créez un secret pour celle-ci. Définissez la date d’expiration en fonction de la fréquence à laquelle vous prévoyez de permuter le secret.
• Enregistrer les valeurs de manière sécurisée : stockez le secret, l’ID d’application (ID client) et l’ID de locataire, car vous en avez besoin pour vous authentifier avec le principal de service. Utilisez un emplacement sécurisé, comme un coffre de mots de passe d’organisation. (Si vous devez demander la création d’une inscription d’application auprès du service informatique, spécifiez que vous avez besoin de ces valeurs.)
• Créer un groupe de sécurité : créez (ou demandez) un groupe de sécurité à utiliser pour Power BI. Utilisez un nom de groupe comme Principaux de service d’administration Power BI, qui signifie que le groupe est utilisé pour accéder aux métadonnées à l’échelle du locataire.
• Ajouter le principal de service comme membre du groupe de sécurité : utilisez l’ID d’application (ID client) pour ajouter le principal de service nouveau (ou existant) comme membre du nouveau groupe de sécurité.
• Mettre à jour le paramètre de locataire d’API d’administration dans Power BI : dans le portail d’administration Power BI, ajoutez le groupe de sécurité au paramètre de locataire Autoriser les principaux de service à utiliser les API d’administration Power BI en lecture seule.
• Ignorer l’attribution d’autorisations dans Azure : ne déléguez aucune autorisation à l’inscription d’application (sinon elle a accès aux données d’audit au niveau du locataire Power BI par le biais du paramètre de locataire Power BI Autoriser les principaux de service à utiliser les API d’administration Power BI en lecture seule).
• Choisir si l’inscription d’application doit accéder aux métadonnées détaillées : déterminez si vous voulez extraire les informations détaillées des tables, colonnes et expressions de mesure dans les modèles sémantiques quand vous créez votre inventaire de locataire.
• Mettre à jour les paramètres de locataire des métadonnées détaillés dans Power BI : si vous le souhaitez, dans le portail d’administration Power BI, ajoutez le groupe de sécurité au paramètre de locataire Améliorer les réponses des API d’administration avec des métadonnées détaillées et au paramètre de locataire Améliorer les réponses des API d’administration avec des expressions DAX et mashup.
• Tester le principal de service : créez un script simple pour vous connecter en utilisant le principal de service et vérifiez qu’il peut récupérer des données à partir d’une API d’administration.
• Créer un processus pour gérer les secrets d’inscription d’application : créez une documentation et un processus pour permuter régulièrement les secrets. Déterminez comment communiquer de manière sécurisée un nouveau secret à tous les administrateurs et développeurs qui en ont besoin.

Définir les paramètres du locataire Power BI

Il y a plusieurs paramètres de locataire dans le portail d’administration Power BI pour extraire les données d’audit au niveau du locataire.

API d’administration

Trois paramètres de locataire permettent d’exécuter des API d’administration.

Important

Comme ces paramètres accordent l’accès aux métadonnées sur l’ensemble du locataire (sans attribuer d’autorisations Power BI directes), vous devez les contrôler étroitement.

Le paramètre de locataire Autoriser les principaux de service à utiliser les API d’administration Power BI en lecture seule vous permet de définir les principaux de service qui peuvent appeler des API d’administration. Ce paramètre permet également à Microsoft Purview d’analyser l’intégralité du locataire Power BI pour remplir le catalogue de données.

Notes

Vous n’avez pas besoin d’attribuer explicitement d’autres administrateurs Power BI au paramètre de locataire Autoriser les principaux de service à utiliser les API d’administration Power BI en lecture seule, car ils ont déjà accès aux métadonnées à l’échelle du locataire.

Le paramètre de locataire Améliorer les réponses des API d’administration avec des métadonnées détaillées vous permet de définir les utilisateurs et principaux de service qui peuvent récupérer des métadonnées détaillées. Les métadonnées sont récupérées à partir des API d’analyse des métadonnées, et sont les tables, les colonnes, etc. Ce paramètre permet également à Microsoft Purview d’accéder aux informations du schéma concernant les modèles sémantiques Power BI pour les stocker dans le catalogue de données.

Le paramètre de locataire Améliorer les réponses des API d’administration avec des expressions DAX et mashup vous permet de définir les utilisateurs et principaux de service qui peuvent récupérer des métadonnées détaillées. Les métadonnées sont récupérées à partir des API d’analyse des métadonnées, et peuvent être des requêtes et des expressions de mesure de modèles sémantiques.

Remarque

Le paramètre de locataire Autoriser les principaux de service à utiliser les API d’administration Power BI en lecture seule concerne spécifiquement l’accès aux API d’administration. Son nom est très similaire au paramètre de locataire qui permet d’accéder aux API utilisateur (décrit ci-dessous). Pour plus d’informations sur la différence entre les API d’administration et les API utilisateur, consultez Choisir une API utilisateur ou une API d’administration plus haut dans cet article.

API utilisateur

Il y a un paramètre de locataire pour appeler les API utilisateur. Dans ce cas, le principal de service a aussi besoin d’autorisations Power BI (par exemple, un rôle d’espace de travail).

Le paramètre de locataire Autoriser les principaux de service à utiliser les API Power BI vous permet de définir les principaux de service qui peuvent exécuter les API REST (à l’exception des API d’administration, qui sont accordées par un autre paramètre de locataire, décrit ci-dessus).

Il existe d’autres paramètres de locataire liés aux API qui permettent d’accéder aux API d’incorporation, aux API de streaming, aux API d’exportation et à l’API d’exécution des requêtes . Toutefois, ces API ne sont pas décrites dans cet article.

Pour plus d’informations sur les paramètres de locataire pour les métriques d’utilisation, consultez Audit au niveau du rapport.

Check-list : voici les décisions et actions clés à prendre en compte pour configurer les paramètres de locataire Power BI :

• Vérifier que chaque principal de service se trouve dans le groupe approprié : vérifiez que le groupe Principaux de service d’administration Power BI comprend les principaux de service appropriés.
• Mettre à jour le paramètre de locataire des API d’administration dans Power BI : ajoutez le groupe de sécurité au paramètre de locataire Autoriser les principaux de service à utiliser les API d’administration Power BI en lecture seule, afin de pouvoir utiliser les API d’administration pour récupérer les métadonnées à l’échelle du locataire.
• Mettre à jour les paramètres de locataire des métadonnées détaillés dans Power BI : si nécessaire, ajoutez le groupe de sécurité au paramètre de locataire Améliorer les réponses des API d’administration avec des métadonnées détaillées et au paramètre de locataire Améliorer les réponses des API d’administration avec des expressions DAX et mashup.
• Déterminer les API utilisateur auxquelles vous devez accéder : vérifiez si une ou plusieurs API utilisateur sont nécessaires (en plus des API d’administration).
• Mettre à jour le paramètre de locataire des API utilisateur dans Power BI : ajoutez le groupe de sécurité au paramètre de locataire Autoriser les principaux de service à utiliser les API Power BI, destiné aux API utilisateur.

Phase 3 : Développement de la solution et analytique

La troisième phase de planification et d’implémentation d’une solution d’audit au niveau du locataire se concentre sur le développement de la solution et l’analytique. À ce stade, vous avez terminé la planification et pris toutes les décisions nécessaires. Vous avez également mis en place les prérequis et effectué la configuration. Vous êtes maintenant prêt à commencer le développement de la solution pour effectuer l’analytique et obtenir des insights à partir de vos données d’audit.

Extraire et stocker les données brutes

À ce stade, vos exigences et priorités doivent être claires. Les principales décisions techniques ont été prises concernant l’accès aux données d’audit et l’emplacement où les stocker. Les outils préférés ont été sélectionnés, et les prérequis et les paramètres ont été configurés. Au cours des deux phases précédentes, vous avez peut-être effectué un ou plusieurs petits projets (preuves de concept) pour tester la faisabilité. L’étape suivante consiste à configurer un processus pour extraire et stocker les données d’audit brutes.

Comme pour les données renvoyées par la plupart des API Microsoft, les données d’audit sont mises en forme au format JSON. Les données au format JSON s’autodécrivent, car c’est un format de texte lisible qui contient la structure et les données.

Le format JSON représente des objets de données constitués de paires attribut-valeur et de tableaux. Par exemple, "state": "Active" montre que la valeur de l’attribut state est Active. Un tableau JSON contient une liste ordonnée d’éléments séparés par une virgule et placés entre crochets ([ ]). On trouve souvent des tableaux imbriqués dans les résultats JSON. Dès que vous êtes familiarisé avec la structure hiérarchique d’un résultat JSON, la structure des données est facile à comprendre, comme une liste (tableau) de modèles sémantiques dans un espace de travail.

Voici quelques points à prendre en compte quand vous extrayez et stockez les données brutes récupérées à partir des API.

• Quelle convention de nommage utiliser ? Pour un système basé sur des fichiers, une convention de nommage est nécessaire pour les fichiers, les dossiers et les zones de lac de données. Pour une base de données, une convention de nommage est nécessaire pour les tables et les colonnes.
• Quel format utiliser pour stocker les données brutes ? Power BI continuant à introduire de nouvelles fonctionnalités, de nouvelles activités, qui n’existent pas aujourd’hui, apparaîtront. Pour cette raison, nous vous recommandons d’extraire et de conserver les résultats JSON d’origine. N’analysez pas, ne filtrez pas ni ne mettez en forme les données pendant leur extraction. De cette façon, vous pouvez utiliser les données brutes d’origine pour regénérer vos données d’audit organisées.
• Quel emplacement de stockage utiliser ? Un lac de données ou un stockage blob est couramment utilisé pour stocker des données brutes. Pour plus d’informations, consultez Déterminer où stocker les données d’audit plus haut dans cet article.
• Quelle quantité d’historique stocker ? Exportez les données d’audit vers un emplacement où vous pouvez stocker l’historique. Prévoyez d’accumuler au moins deux ans d’historique. De cette façon, vous pouvez analyser les tendances et les changements au-delà de la période de conservation de 30 jours par défaut. Vous pouvez choisir de stocker les données indéfiniment, ou sur une période plus courte, en fonction des stratégies de conservation de données de votre organisation.
• Comment savoir quand le processus s’est exécuté pour la dernière fois ? Définissez un fichier de configuration, ou l’équivalent, pour enregistrer les horodatages au début et à la fin d’un processus. À la prochaine exécution du processus, il peut récupérer ces horodatages. Il est particulièrement important de stocker les horodatages quand vous extrayez les données avec les API d’analyse des métadonnées.
• Comment gérer les limitations ? Certaines API REST Power BI et l’API Microsoft Graph implémentent une limitation. Vous recevez une erreur 429 (trop de demandes) si votre demande d’API est limitée. Les grandes organisations qui ont besoin de récupérer un grand volume de données sont souvent confrontées au problème de limitation. La technologie que vous utilisez pour accéder aux données et les extraire détermine comment éviter l’échec des tentatives lié à une limitation. Vous pouvez développer une logique dans vos scripts qui répond à l’erreur 429 « Trop de demandes » en réessayant après une période d’attente.
• Les données d’audit sont-elles nécessaires pour la conformité ? De nombreuses organisations utilisent les enregistrements de journal d’audit bruts pour effectuer des audits de conformité ou répondre à des investigations de sécurité. Dans ce cas, nous vous recommandons vivement de stocker les données brutes dans un stockage immuable. De cette façon, une fois les données écrites, elles ne peuvent être ni modifiées ni supprimées par un administrateur ou un autre utilisateur.
• Quelles sont les couches de stockage nécessaires pour répondre à vos besoins ? Le meilleur endroit pour stocker les données brutes est un lac de données (comme Azure Data Lake Storage Gen2) ou un stockage d’objets (comme le Stockage Blob Azure). Vous pouvez aussi utiliser un système de fichiers si les services cloud ne sont pas une option.

Check-list : voici les décisions et actions clés à prendre en compte pour extraire et stocker les données brutes :

• Confirmer les exigences et les priorités : clarifiez les exigences et les priorités concernant les données que vous allez extraire en premier.
• Confirmer la source des données à extraire : vérifiez la source pour chaque type de données dont vous avez besoin.
• Configurer un processus pour extraire les données et les charger dans la zone de données brutes : créez le processus initial pour extraire et charger les données brutes dans leur état d’origine, sans aucune transformation. Faites des tests pour vérifier que le processus fonctionne comme prévu.
• Créer une planification pour exécuter les processus : configurez une planification récurrente pour exécuter les processus d’extraction, de chargement et de transformation.
• Vérifier que les informations d’identification sont gérées de manière sécurisée : vérifiez que les mots de passe, les secrets et les clés sont stockés et communiqués de manière sécurisée.
• Vérifier que la sécurité est correctement configurée : vérifiez que les autorisations d’accès sont correctement configurées pour les données brutes. Vérifiez que les administrateurs et les auditeurs peuvent accéder aux données brutes.

Pour plus d’informations sur le développement au fil du temps d’une solution d’audit et de monitoring, consultez Opérationnaliser et améliorer plus loin dans cet article.

Créer les données organisées

À ce stade, les données brutes sont extraites et stockées. L’étape suivante consiste à créer une couche or distincte pour les données organisées. Son objectif est de transformer et stocker les fichiers de données dans un schéma en étoile. Un schéma en étoile comprend des tables de dimension et des tables de faits, et est intentionnellement optimisé pour l’analyse et la création de rapports. Les fichiers de la couche de données organisées deviennent la source d’un modèle de données Power BI (décrit dans la rubrique suivante).

Conseil

Quand vous prévoyez plusieurs modèles de données, pensez à investir dans une couche de données organisées centralisée.

Check-list : voici les décisions et actions clés à prendre en compte pour créer la couche de données organisées :

• Confirmer les exigences et les priorités : si vous envisagez d’utiliser une couche argent intermédiaire pour les données transformées, clarifiez les exigences et les objectifs de ce que vous devez faire.
• Configurer un processus pour transformer les données brutes et les charger dans la zone de données organisées : créez un processus pour transformer et charger les données dans un schéma en étoile. Faites des tests pour vérifier que le processus fonctionne comme prévu.
• Créer une planification pour exécuter les processus : configurez une planification récurrente pour remplir la couche de données organisées.
• Vérifier que la sécurité est correctement configurée : vérifiez que les autorisations d’accès sont correctement configurées pour les données organisées. Vérifiez que les développeurs du modèle de données peuvent accéder aux données organisées.

Créer un modèle de données

La rubrique décrit la configuration d’un modèle de données analytique. Un modèle de données est une ressource de données interrogeable optimisée pour l’analytique. On parle parfois de modèle sémantique ou simplement de modèle. Pour votre solution d’audit et de monitoring, le modèle de données est probablement implémenté sous forme de modèle sémantique Power BI.

Dans le contexte des audits et de la surveillance, un modèle de données se procure des données à partir de la couche de données organisées (or). Si vous choisissez de ne pas créer de couche de données organisées, le modèle de données se procure les données directement à partir des données brutes.

Nous vous recommandons d’adopter un modèle de données Power BI qui implémente une conception de schéma en étoile. Quand les données viennent de la couche de données organisées, le schéma en étoile du modèle de données Power BI doit refléter le schéma en étoile de la couche de données organisées.

Conseil

Pour avoir une vue d’ensemble de la conception d’un schéma en étoile, consultez Comprendre le schéma en étoile et son importance pour Power BI.

Comme pour tout projet Power BI, la création d’un modèle de données est un processus itératif. Vous pouvez ajouter de nouvelles mesures selon vos besoins. Vous pouvez également ajouter de nouvelles tables et colonnes à mesure que de nouveaux événements d’audit sont disponibles. Avec le temps, vous pouvez même intégrer de nouvelles sources de données.

Voici quelques tables de dimension utiles que vous pouvez ajouter au modèle de données.

• Date : ensemble d’attributs de date permettant d’analyser (découper) les données par jour, semaine, mois, trimestre, année et autres intervalles pertinents.
• Heure : si vous avez besoin d’une analyse heure par heure et que vous avez un très grand volume de données d’audit, stockez les heures séparément des dates. Cette approche permet d’améliorer les performances des requêtes.
• Utilisateurs : attributs qui décrivent les utilisateurs (comme le service et la région géographique) pouvant filtrer de nombreux sujets de données d’audit. L’objectif est de supprimer tous les détails utilisateur des tables de faits et de les stocker dans cette table de dimension pour qu’ils puissent filtrer de nombreuses tables de faits. Vous pouvez également stocker les principaux de service dans cette table.
• Événements d’activité : attributs qui regroupent et décrivent les événements d’activité (opérations). Pour améliorer vos rapports, vous pouvez créer un dictionnaire de données qui décrit chaque événement d’activité. Vous pouvez également créer une hiérarchie qui regroupe et classifie des événements d’activité similaires. Par exemple, vous pouvez regrouper tous les événements de création d’élément, les événements de suppression, etc.
• Espaces de travail : liste des espaces de travail du locataire et des propriétés d’espace de travail, comme le type (personnel ou standard) et la description. Certaines organisations enregistrent plus de détails sur les espaces de travail (éventuellement avec une liste SharePoint). Vous pouvez intégrer ces détails dans cette table de dimension. Vous devez choisir si cette table de dimension stocke uniquement l’état actuel de l’espace de travail ou si elle stocke des données versionées qui reflètent des changements significatifs de l’espace de travail au fil du temps. Par exemple, quand le nom d’un espace de travail change, les rapports historiques montrent-ils le nom de l’espace de travail actuel ou le nom de l’espace de travail tel qu’il était à ce moment-là ? Pour plus d’informations sur le versioning, consultez Dimensions à variation lente.
• Types d’élément : liste des types d’élément Power BI (modèles sémantiques, rapports, etc.).
• Capacités : liste des capacités Premium dans le locataire.
• Passerelles : liste des passerelles de données dans le locataire.
• Sources de données : liste des sources de données utilisées par un modèle sémantique, flux de données ou datamart.

Voici quelques tables de faits (sujets) utiles que vous pouvez ajouter au modèle de données.

• Activités utilisateur : données de faits provenant des données JSON d’origine. Tous les attributs qui n’ont pas de valeur analytique sont supprimés. Tous les attributs qui appartiennent aux tables de dimension (ci-dessus) sont également supprimés.
• Inventaire du locataire : instantané à un point dans le temps de tous les éléments publiés dans le locataire. Pour plus d'informations, consultez Inventaire du locataire plus haut dans cet article.
• Modèles sémantiques : inclut l’activité utilisateur impliquant des modèles sémantiques (comme des modifications de modèle sémantique) ou des sources de données associées.
• Actualisations de modèle sémantique : stocke les opérations d’actualisation des données, notamment des détails sur le type (planifiée ou à la demande), la durée, l’état et l’utilisateur qui a lancé l’opération.
• Rôles d’espace de travail : instantané des attributions de rôle d’espace de travail à un point dans le temps.
• Licences utilisateur : instantané des licences utilisateur à un point dans le temps. Même si vous pouvez être tenté de stocker la licence utilisateur dans la table de dimension Utilisateurs, cette approche ne prend pas en charge l’analyse des changements et des tendances de licence au fil du temps.
• Appartenances à un groupe d’utilisateurs : instantané à un point dans le temps des utilisateurs (et des principaux de service) attribués à un groupe de sécurité.
• Activités de la communauté : comprend des faits liés à la communauté, comme des événements de formation. Par exemple, vous pouvez analyser les activités utilisateur Power BI par rapport à la participation à la formation. Ces données peuvent aider le centre d’excellence à identifier de nouveaux champions potentiels.

Les tables de faits ne doivent pas avoir de colonnes qui peuvent être filtrées par les créateurs de rapport. Ces colonnes appartiennent aux tables de dimension associées. Non seulement cette conception est plus efficace pour les requêtes, mais elle favorise également la réutilisation des tables de dimension par plusieurs faits (appelés exploration horizontale). Ce dernier point est important pour produire un modèle de données utile et convivial, extensible quand vous ajoutez de nouvelles tables de faits (sujets).

Par exemple, la table de dimension Utilisateurs est liée à chaque table de faits. Elle doit être liée à la table de faits Activités utilisateur (qui a effectué l’activité), à la table de faits Inventaire du locataire (qui a créé l’élément publié) et à toutes les autres tables de faits. Quand un rapport est filtré sur un utilisateur dans la table de dimension Utilisateurs, les visuels de ce rapport peuvent montrer pour cet utilisateur des faits de n’importe quelle table de faits associée.

Quand vous concevez votre modèle, vérifiez qu’un même attribut est visible une seule fois dans le modèle. Par exemple, l’adresse e-mail de l’utilisateur doit être visible seulement dans la table de dimension Utilisateurs. Il existe également dans d’autres tables de faits (comme clé de dimension pour prendre en charge une relation de modèle). Toutefois, vous devez le masquer dans chaque table de faits.

Nous vous recommandons de créer votre modèle de données séparément des rapports. Le découplage d’un modèle sémantique et de ses rapports engendre un modèle sémantique centralisé qui peut servir de nombreux rapports. Pour plus d’informations sur l’utilisation d’un modèle sémantique partagé, consultez le scénario d’utilisation BI libre-service managé.

Configurez la sécurité au niveau des lignes (SNL) pour que d’autres utilisateurs (en dehors du centre d’excellence, des auditeurs et des administrateurs) puissent analyser les données d’audit et créer des rapports. Par exemple, vous pouvez utiliser des règles SNL pour permettre aux créateurs de contenu et aux consommateurs de créer des rapports sur leurs propres activités utilisateur ou efforts de développement.

Check-list : voici les décisions et actions clés à prendre en compte pour créer le modèle de données :

• Planifier et créer le modèle de données : concevez le modèle de données sous forme de schéma en étoile. Vérifiez que les relations fonctionnent comme prévu. Quand vous développez le modèle, créez des mesures de manière itérative et ajoutez des données supplémentaires en fonction des exigences analytiques. Ajoutez les améliorations futures dans un backlog, si nécessaire.
• Configurer la sécurité au niveau des lignes : si vous voulez mettre le modèle de données à la disposition d’autres utilisateurs généraux, configurez la sécurité au niveau des lignes pour restreindre l’accès aux données. Vérifiez que les rôles SNL renvoient les données correctes.

améliorer le modèle de données

Pour analyser efficacement l’utilisation du contenu et les activités utilisateur, nous vous recommandons d’enrichir votre modèle de données. Les améliorations du modèle de données peuvent être effectuées progressivement et de manière itérative au fil du temps en fonction des opportunités et des nouvelles exigences.

Créer des classifications

Une façon d’améliorer le modèle et d’augmenter la valeur de vos données est d’ajouter des classifications au modèle de données. Vérifiez que ces classifications sont utilisées de manière cohérente par vos rapports.

Vous pouvez choisir de classer les utilisateurs en fonction de leur niveau d’utilisation ou de classer le contenu en fonction de son niveau d’utilisation.

Classification de l’utilisation des utilisateurs

Tenez compte des classifications suivantes pour l’utilisation des utilisateurs.

• Utilisateur fréquent : activité enregistrée au cours de la dernière semaine et de neuf des 12 derniers mois.
• Utilisateur actif : activité enregistrée au cours du dernier mois.
• Utilisateur occasionnel : activité enregistrée au cours des neuf derniers mois, mais sans activité au cours du dernier mois.
• Utilisateur inactif : aucune activité enregistrée au cours des neuf derniers mois.

Conseil

Il est utile de savoir qui sont vos utilisateurs occasionnels ou inactifs, en particulier quand ils ont des licences Pro ou PPU (qui impliquent des coûts). Il est également utile de savoir qui sont vos utilisateurs fréquents et les plus actifs. Invitez-les à rejoindre les heures de bureau ou à participer à une formation. Vos créateurs de contenu les plus actifs peuvent être des candidats pour votre réseau de champions.

Classification de l’utilisation du contenu

Tenez compte des classifications suivantes pour l’utilisation du contenu.

• Contenu souvent utilisé : activité enregistrée au cours de la dernière semaine et de neuf des 12 derniers mois.
• Contenu activement utilisé : activité enregistrée au cours du dernier mois.
• Contenu occasionnellement utilisé : activité enregistrée au cours des neuf derniers mois, mais sans activité au cours du dernier mois.
• Contenu inutilisé : aucune activité enregistrée au cours des neuf derniers mois.

Classification des types d’utilisateur

Tenez compte des classifications suivantes pour le type d’utilisateur.

• Créateur de contenu : activité enregistrée au cours des six derniers mois, qui a créé, publié ou modifié du contenu.
• Lecteur de contenu : activité enregistrée au cours des six derniers mois, qui a consulté le contenu, mais sans aucune activité de création de contenu.

Prendre en compte la récence et les tendances

Vous devez décider si les classifications d’utilisation pour les utilisateurs ou le contenu doivent être basées uniquement sur la récence d’une activité. Vous pouvez aussi prendre en compte l’utilisation moyenne ou la tendance d’utilisation au fil du temps.

Prenons quelques exemples qui montrent comment une logique de classification simple peut fausser la réalité.

• Un responsable a consulté un rapport cette semaine. Toutefois, avant cette semaine, le responsable n’avait consulté aucun rapport au cours des six derniers mois. Vous ne devez pas considérer ce responsable comme un utilisateur fréquent uniquement en fonction de l’utilisation récente.
• Un créateur de rapport publie un nouveau rapport chaque semaine. Quand vous analysez l’utilisation selon les utilisateurs fréquents, l’activité régulière du créateur de rapport semble positive. Toutefois, après une investigation plus approfondie, vous découvrez que cet utilisateur a publié un nouveau rapport (sous un nouveau nom) chaque fois qu’il modifie le rapport. Ici, le créateur de rapport a besoin d’une formation.
• Un cadre consulte un rapport de façon sporadique, sa classification d’utilisation change souvent. Vous devez peut-être analyser certains types d’utilisateur, comme les cadres, de manière différente.
• Un auditeur interne consulte des rapports critiques une fois par an. L’auditeur interne pourrait s’apparenter à un utilisateur inactif en raison de son utilisation peu fréquente. Quelqu’un pourrait décider de supprimer sa licence Pro ou PPU. Ou bien, quelqu’un pourrait penser que le rapport doit être retiré, car il est rarement utilisé.

Conseil

Vous pouvez calculer des moyennes et des tendances en utilisant des fonctions DAX Time Intelligence. Pour savoir comment utiliser ces fonctions, suivez le module d’apprentissage Utiliser des fonctions Time Intelligence DAX dans les modèles Power BI Desktop.

Check-list : voici les décisions et actions clés à prendre en compte pour créer des données de classification d’utilisation :

• Obtenir un consensus sur les définitions de classification : discutez des définitions de classification avec les parties prenantes concernées. Vérifiez que tout le monde est d’accord avec la décision prise.
• Créer la documentation : vérifiez que les définitions de classification sont ajoutées à la documentation destinée aux créateurs de contenu et aux consommateurs.
• Créer une boucle de rétroaction : vérifiez qu’il y a un moyen pour les utilisateurs de poser des questions ou de proposer des changements pour les définitions de classification.

Créer des rapports analytiques

À ce stade, les données d’audit ont été extraites et stockées, et vous avez publié un modèle de données. L'étape suivante est de créer des rapports analytiques.

Concentrez-vous sur les informations clés adaptées à chaque audience. Vous pouvez avoir plusieurs audiences pour vos rapports d’audit. Chaque audience s’intéresse à des informations différentes, pour des utilisations différentes. Les audiences que vous pouvez servir avec vos rapports sont les suivantes :

• Sponsor exécutif
• Centre d’excellence
• Administrateurs Power BI
• Administrateurs d’espace de travail
• Administrateurs de capacité Premium
• Administrateurs de passerelle
• Développeurs et créateurs de contenu Power BI
• Auditeurs

Voici quelques-unes des exigences analytiques les plus courantes par lesquelles vous souhaiterez sans doute démarrer lors de la création de vos rapports d’audit.

• Principales vues de contenu : vos équipes dirigeantes seront sans doute principalement intéressées par les informations récapitulatives et les tendances au fil du temps. Les administrateurs, développeurs et créateurs de contenu d’espace de travail sont plus intéressés par les détails.
• Principales activités utilisateur : votre centre d’excellence veut savoir qui utilise Power BI, comment et quand. Les administrateurs de capacité Premium veulent savoir qui utilise la capacité pour garantir son intégrité et sa stabilité.
• Inventaire du locataire : vos administrateurs Power BI, administrateurs d’espace de travail et auditeurs veulent comprendre quel contenu existe, où, sa traçabilité et ses paramètres de sécurité.

Cette liste n’est pas exhaustive. Ces exemples vous donnent des idées sur la façon de créer des rapports analytiques qui ciblent des besoins spécifiques. Pour plus d’informations, consultez Données nécessaires plus haut dans cet article et Vue d’ensemble de l’audit et du monitoring. Ces ressources proposent de nombreuses idées d’utilisation des données d’audit et le type d’informations que vous pouvez choisir de présenter dans vos rapports.

Conseil

Bien qu’il soit tentant de présenter un grand nombre de données, limitez-vous aux informations sur lesquelles vous pouvez agir. Vérifiez que chaque page de rapport indique clairement son objectif, l’action qui doit être effectuée et par qui.

Pour savoir comment créer des rapports analytiques, suivez le parcours d’apprentissage Concevoir des rapports efficaces dans Power BI.

Check-list : voici les décisions et actions clés pour planifier des rapports d’audit analytiques :

• Passer en revue les exigences : donnez la priorité aux rapports basés sur des besoins connus et des questions spécifiques auxquelles vous devez répondre.
• Confirmer votre ou vos audiences : vérifiez qui utilise les rapports d’audit et quel est leur objectif.
• Créer et déployer des rapports : développez le premier ensemble de rapports de base. Étendez-les et améliorez-les progressivement au fil du temps.
• Distribuer les rapports dans une application : créez une application qui comprend tous vos rapports d’audit et de monitoring.
• Vérifier qui a accès aux rapports : vérifiez que les rapports (ou l’application) sont disponibles pour les bons utilisateurs.
• Créer une boucle de rétroaction : vérifiez qu’il y a un moyen pour les consommateurs de rapports de fournir des commentaires ou des suggestions, ou de signaler des problèmes.

Effectuer des actions en fonction des données

Les données d’audit sont précieuses, car elles vous aident à comprendre ce qui se passe dans votre locataire Power BI. Bien que cela puisse sembler évident, prendre explicitement les mesures qui s’imposent en fonction des informations apportées par les données d’audit peut être facilement négligé. Pour cette raison, nous vous recommandons de désigner une personne responsable du suivi des améliorations mesurables, au lieu de simplement passer en revue les rapports d’audit. De cette façon, vous pouvez avancer progressivement et de façon mesurable dans votre adoption de Power BI et faire évoluer votre niveau de maturité concernant l’outil.

Vous pouvez effectuer de nombreuses actions différentes en fonction de vos objectifs et de ce que les données d’audit vous apprennent. Le reste de cette section vous donne plusieurs idées.

Utilisation du contenu

Voici quelques actions que vous pouvez effectuer en fonction de la façon dont le contenu est utilisé.

• Le contenu est fréquemment utilisé (tous les jours ou toutes les semaines) : vérifiez que le contenu critique est certifié. Vérifiez que la propriété est claire et que la solution a un support approprié.
• Nombre élevé de vues d’espace de travail : en cas de nombre élevé de vues d’espace de travail, investiguez pourquoi les applications Power BI ne sont pas utilisées.
• Le contenu est rarement utilisé : contactez les utilisateurs cibles pour déterminer si la solution répond à leurs besoins ou si leurs exigences ont changé.
• L’activité d’actualisation se produit plus fréquemment que les consultations : contactez le propriétaire du contenu pour comprendre pourquoi un jeu de données est actualisé régulièrement sans utilisation récente du modèle sémantique ou des rapports associés.

Activités de l’utilisateur

Voici quelques actions que vous pouvez effectuer en fonction des activités utilisateur.

• Première action de publication par un nouvel utilisateur : identifiez quand un type d’utilisateur passe de consommateur à créateur, c’est-à-dire quand il publie du contenu pour la première fois. C’est une excellente occasion de lui envoyer un e-mail standard avec des conseils et des liens vers des ressources utiles.
• Engagement avec les créateurs de contenu les plus fréquents : invitez vos créateurs les plus actifs à rejoindre votre réseau de champions ou à s’impliquer dans votre communauté de pratique.
• Gestion des licences : vérifiez si les créateurs inactifs ont toujours besoin d’une licence Pro ou PPU.
• Activation d’une version d’essai utilisateur : L’activation d’une licence d’essai peut vous inviter à attribuer une licence permanente à l’utilisateur avant la fin de son essai.

Opportunités de formation des utilisateurs

Voici quelques opportunités de formation des utilisateurs que vous pouvez identifier à partir des données d’audit.

• Nombre élevé de modèles sémantiques publiés par le même créateur de contenu : expliquez aux utilisateurs comment utiliser les modèles sémantiques partagés et pourquoi il vaut mieux éviter de créer des modèles sémantiques en double.
• Partage excessif à partir d’un espace de travail personnel : contactez l’utilisateur qui effectue beaucoup de partages à partir de son espace de travail personnel. Expliquez-lui les espaces de travail standard.
• Nombre significatif de vues de rapport à partir d’un espace de travail personnel : contactez l’utilisateur propriétaire du contenu qui a un nombre élevé de vues de rapport. Expliquez-lui pourquoi les espaces de travail standard sont préférables aux espaces de travail personnels.

Conseil

Vous pouvez également améliorer votre contenu de formation ou votre documentation en passant en revue les questions auxquelles votre communauté Power BI interne a répondu et les problèmes envoyés au support technique.

Sécurité

Voici quelques situations de sécurité que vous souhaiterez sans doute surveiller de manière active.

• Trop d’utilisateurs sont affectés au rôle Administrateur Fabric à privilèges élevés.
• Trop d’administrateurs d’espace de travail (alors que le rôle d’espace de travail Membre, Contributeur ou Lecteur est suffisant).
• Trop d’autorisations de génération attribuées aux modèles sémantiques (alors que l’autorisation de lecture est suffisante).
• Grande utilisation des autorisations par élément, alors que les autorisations d’application Power BI ou le rôle Lecteur d’espace de travail sont plus adaptés pour les consommateurs de contenu.
• Comment le contenu est partagé avec les utilisateurs externes.

Pour plus d’informations, consultez les articles sur la Planification de la sécurité.

Gouvernance et atténuation des risques

Voici quelques situations que vous allez sans doute rencontrer. Recherchez explicitement ces types de situation dans vos rapports d’audit, pour être prêt à agir rapidement.

• Nombre élevé de vues pour des rapports (et des modèles sémantiques sous-jacents) qui ne sont pas approuvés.
• Utilisation importante de sources de données inconnues ou non approuvées.
• Emplacements de fichiers qui ne suivent pas les directives de gouvernance sur l’emplacement des fichiers sources.
• Noms d’espace de travail qui ne sont pas alignés sur les exigences de gouvernance.
• Des étiquettes de confidentialité sont utilisées pour la protection des informations.
• Échecs systématiques d’actualisation des données.
• Utilisation importante et récurrente de l’impression.
• Utilisation inattendue ou excessive des abonnements.
• Utilisation inattendue de passerelles personnelles.

Les actions spécifiques à effectuer dans chaque situation dépendent de vos stratégies de gouvernance. Pour plus d’informations, consultez Gouvernance dans la feuille de route d’adoption de Fabric.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier des actions potentielles en fonction des données d’audit :

• Clarifier les attentes : créez des rapports d’audit avec un ensemble clair d’attentes pour les actions attendues.
• Clarifier qui est responsable des actions : vérifiez que les rôles et les responsabilités sont attribués.
• Créer une automatisation : si possible, automatisez les actions connues qui sont reproductibles.
• Utiliser un système de suivi : utilisez un système pour suivre une situation observée, y compris le contact effectué, l’action planifiée suivante, la personne responsable, la résolution et l’état.

Phase 4 : Maintenir, améliorer et monitorer

La quatrième phase de planification et d’implémentation d’une solution d’audit au niveau du locataire se concentre sur la maintenance, les améliorations et le monitoring. À ce stade, votre solution d’audit est en production. Vous vous occupez désormais principalement de la maintenance, de l’amélioration et du monitoring de la solution.

Opérationnaliser et améliorer

Les processus d’audit sont généralement considérés en production quand le développement et les tests initiaux sont terminés et que vous avez automatisé le processus. Les processus d’audit automatisés s’exécutant en production ont des attentes plus élevées (que les processus manuels) en matière de qualité, de fiabilité, de stabilité et de support.

Un processus d’audit au niveau de la production a été opérationnalisé. Une solution opérationnalisée comprend généralement un grand nombre des caractéristiques suivantes.

• Sécurisé : les informations d’identification sont stockées et gérées de manière sécurisée. Les scripts ne contiennent pas de mots de passe ni de clés en texte clair.
• Planification : un système de planification fiable est en place.
• Gestion des changements : l’utilisation de pratiques de gestion des changements et de plusieurs environnements permet de garantir la protection de l’environnement de production. Vous pouvez également utiliser des environnements de développement et de test, ou simplement un environnement de développement.
• Support : l’équipe chargée du support de la solution est clairement définie. Les membres de l’équipe ont été formés et comprennent les attentes opérationnelles. Les remplaçants ont été identifiés et une formation croisée est en place selon les besoins.
• Alertes : en cas de problème, des alertes avertissent automatiquement l’équipe de support. De préférence, les alertes comprennent à la fois des journaux et des e-mails (plutôt que des e-mails uniquement). Un journal est utile pour analyser les erreurs et les avertissements journalisés.
• Journalisation : les processus sont journalisés pour avoir un historique de la mise à jour des données d’audit. Les informations journalisées doivent enregistrer l’heure de début, l’heure de fin, et l’identité de l’utilisateur ou de l’application qui a exécuté le processus.
• Gestion des erreurs : les scripts et les processus gèrent et journalisent les erreurs de manière appropriée (par exemple, s’il faut arrêter immédiatement, continuer, ou attendre et réessayer). Des notifications d’alerte sont envoyées à l’équipe de support quand une erreur se produit.
• Standards de codage : de bonnes techniques de codage qui fonctionnent bien sont utilisées. Par exemple, les boucles sont volontairement évitées, sauf si nécessaire. Des standards de codage cohérents, des commentaires, une mise en forme et une syntaxe sont utilisés pour faciliter la maintenance et le support de la solution.
• Réutilisation et modularisation : pour réduire la duplication, le code et les valeurs de configuration (comme les chaînes de connexion ou les adresses e-mail pour les notifications) sont modularisés afin que d’autres scripts et processus puissent les réutiliser.

Conseil

Vous n’avez pas besoin de faire tout ce qui est listé ci-dessus au même moment. À mesure que vous gagnez de l’expérience, vous pouvez améliorer de manière incrémentielle la solution pour qu’elle soit plus complète et robuste. N’oubliez pas que la plupart des exemples que vous trouvez en ligne sont des extraits de script simples et ponctuels qui n’auront peut-être pas une qualité de production.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier l’opérationnalisation et l’amélioration d’une solution d’audit :

• Évaluer le niveau des solutions existantes : déterminez les possibilités d’amélioration et de stabilisation des solutions d’audit existantes automatisées.
• Établir des standards de niveau production : déterminez les standards que vous voulez avoir pour vos processus d’audit automatisés. Réfléchissez aux améliorations que vous pouvez ajouter de manière réaliste au fil du temps.
• Créer un plan d’amélioration : planifiez l’amélioration de la qualité et de la stabilité des solutions d’audit de production.
• Déterminer si un environnement de développement distinct est nécessaire : évaluez le niveau de risque et la dépendance vis-à-vis des données de production. Choisissez quand créer des environnements de développement et de production (et de test) distincts.
• Envisager une stratégie de conservation des données : déterminez si vous devez implémenter un processus de conservation des données qui supprime définitivement les données après un certain laps de temps ou sur demande.

Documentation et support

La documentation et le support sont essentiels pour une solution au niveau de la production. Il est utile de créer plusieurs types de documentation, en fonction de l’audience cible et de l’objectif.

Documentation technique

La documentation technique s’adresse à l’équipe technique qui a créé la solution, et qui est chargée de l’améliorer et de la développer progressivement au fil du temps. C’est également une ressource utile pour l’équipe de support.

La documentation technique doit comprendre :

• Un récapitulatif des composants d’architecture et des prérequis.
• Qui détient et gère la solution.
• Qui est chargé du support de la solution.
• Un diagramme d’architecture.
• Les décisions de conception, y compris les objectifs, les raisons pour lesquelles certains choix techniques ont été faits et les contraintes (comme le coût ou les compétences).
• Les décisions et choix en matière de sécurité.
• Les conventions de nommage utilisées.
• Le codage et les standards techniques, et les directives.
• Les exigences de la gestion des changements.
• Les instructions de déploiement, de configuration et d’installation.
• Les domaines connus de dette technique (domaines qui peuvent être améliorés si l’occasion se présente).

Documentation de support

Selon le niveau de criticité de votre solution d’audit, vous pouvez avoir une équipe de support technique ou une équipe de support en cas de problèmes urgents. Elles peuvent être disponibles toute la journée, tous les jours.

La documentation de support est parfois appelée base de connaissances ou runbook. Cette documentation est destinée à votre équipe de support technique ou de support, et doit comprendre :

• Directives de résolution de problèmes le cas échéant. Par exemple, en cas d’échec d’actualisation des données.
• Actions à effectuer de façon continue. Par exemple, des étapes manuelles devront sans doute être effectuées régulièrement jusqu’à la résolution d’un problème.

Documentation du créateur de contenu

Vous tirez davantage de valeur de votre solution d’audit en fournissant une analyse d’utilisation et d’adoption aux autres équipes de l’organisation (en appliquant une sécurité au niveau des lignes, si nécessaire).

La documentation du créateur de contenu s’adresse aux créateurs de contenu en libre-service qui créent des rapports et des modèles de données à partir des données d’audit organisées. Elle comprend des informations sur le modèle de données, y compris des définitions de données courantes.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier la documentation et le support de votre solution d’audit :

• Vérifier qui est chargé du support de la solution : déterminez qui est chargé du support des solutions d’audit au niveau de la production (ou des solutions qui ont des dépendances sur des rapports en aval).
• Vérifier que l’équipe de support est prête : vérifiez que l’équipe de support est prête à effectuer le support de la solution d’audit. Identifiez les éventuelles lacunes en matière de préparation.
• Organiser une formation croisée : organisez des sessions de transfert des connaissances ou des sessions de formation croisée pour l’équipe de support.
• Clarifier les attentes de l’équipe de support : vérifiez que les attentes en matière de réponse et de résolution sont clairement documentées et communiquées. Décidez si quelqu’un doit être d’astreinte pour résoudre rapidement les problèmes liés à la solution d’audit.
• Créer une documentation technique : créez une documentation sur les décisions de conception et d’architecture technique.
• Créer une documentation de support : mettez à jour la base de connaissances du support technique pour y ajouter des informations sur le support de la solution.
• Créer une documentation pour les créateurs de contenu : créez une documentation pour aider les créateurs en libre-service à utiliser le modèle de données. Décrivez les définitions de données courantes pour améliorer la cohérence de l’utilisation.

Activer les alertes

Vous pouvez déclencher des alertes en fonction de conditions spécifiques dans les données d’audit. Par exemple, vous pouvez déclencher une alerte quand quelqu’un supprime une passerelle ou qu’un administrateur Power BI change un paramètre de locataire.

Pour plus d’informations, consultez Monitoring au niveau du locataire.

Gestion continue

Vous devez effectuer une gestion continue de l’ensemble de la solution d’audit. Vous devez peut-être étendre ou changer votre solution d’audit quand :

• L’organisation découvre de nouvelles exigences de données.
• De nouveaux événements d’audit apparaissent dans les données brutes extraites à partir des API REST Power BI.
• Microsoft fait des changements dans les API REST Power BI.
• Les employés identifient des moyens d’améliorer la solution.

Important

Les changements cassants sont rares, mais ils peuvent se produire. Il est important d’avoir une personne disponible capable de résoudre rapidement les problèmes ou de mettre à jour la solution d’audit si nécessaire.

Check-list : voici les décisions et actions clés à prendre en compte pour planifier la gestion continue de la solution d’audit :

• Désigner un propriétaire technique : vérifiez que la propriété et la responsabilité de la solution d’audit sont clairement définies.
• Vérifier qu’il y a un remplaçant : vérifier qu’il y a un propriétaire technique remplaçant capable d’intervenir si un problème urgent survient que le support ne peut pas résoudre.
• Garder un système de suivi : vérifiez que vous avez un moyen de capturer les nouvelles demandes et d’identifier les priorités immédiates, mais aussi les priorités à court terme, à moyen terme et à long terme (backlog).

Contenu connexe

Dans l’article suivant de cette série, découvrez le monitoring au niveau du locataire.