Partager via

Livre blanc Sécurité dans Power BI

Résumé: Power BI est un service logiciel en ligne (SaaS ou Software as a Service) proposé par Microsoft qui vous permet de créer facilement et rapidement des tableaux de bord décisionnels en libre-service, des rapports, des modèles sémantiques et des visualisations. Avec Power BI, vous pouvez vous connecter à de nombreuses sources de données différentes, combiner et mettre en forme des données à partir de ces connexions, puis créer des rapports et des tableaux de bord qui peuvent être partagés avec d’autres utilisateurs.

Écrivains: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Réviseurs techniques : Cristian Petculescu, Amir Netz, Sergei Gundorov

S’applique à : Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI Mobile.

Remarque

Vous pouvez enregistrer ou imprimer ce livre blanc en sélectionnant Imprimer à partir de votre navigateur, puis en sélectionnant Enregistrer au format PDF.

Présentation

Power BI est un service logiciel en ligne (SaaS ou Software as a Service) proposé par Microsoft qui vous permet de créer facilement et rapidement des tableaux de bord décisionnels en libre-service, des rapports, des modèles sémantiques et des visualisations. Avec Power BI, vous pouvez vous connecter à de nombreuses sources de données différentes, combiner et mettre en forme des données à partir de ces connexions, puis créer des rapports et des tableaux de bord qui peuvent être partagés avec d’autres utilisateurs.

Le monde évolue rapidement ; les organisations passent par une transformation numérique accélérée, et nous voyons une augmentation massive du travail à distance, une augmentation de la demande des clients pour les services en ligne et une utilisation accrue des technologies avancées dans les opérations et la prise de décision commerciale. Et tout cela est alimenté par le cloud.

Comme la transition vers le cloud est passée d'un filet à une inondation, et avec la nouvelle surface exposée qui l'accompagne, de plus en plus d'entreprises se demandent Quelle est la sécurité de mes données dans le cloud ? et Quelle protection de bout en bout est disponible pour empêcher la fuite de mes données sensibles ? Et pour les plateformes décisionnelles qui gèrent souvent certaines des informations les plus stratégiques de l'entreprise, ces questions sont doublement importantes.

Les fondements des décennies du modèle de sécurité BI ( sécurité au niveau de l’objet et au niveau des lignes), tout en restant importants, ne suffisent plus clairement pour fournir le type de sécurité nécessaire à l’ère du cloud. Au lieu de cela, les organisations doivent rechercher une solution de sécurité cloud-native, multiniveau et de défense en profondeur pour leurs données décisionnelles.

Power BI a été conçu pour fournir une protection complète et hermétique de pointe pour les données. Le produit a obtenu les classifications de sécurité les plus élevées disponibles dans l’industrie, et aujourd’hui de nombreux organismes de sécurité nationaux, institutions financières et fournisseurs de soins de santé lui confient leurs informations les plus sensibles.

Tout commence par la fondation. Après une période approximative au début des années 2000, Microsoft a fait des investissements massifs pour résoudre ses vulnérabilités de sécurité et, au cours des décennies suivantes, a construit une pile de sécurité forte qui va aussi loin que le noyau bios de la machine à puce et étend tout le chemin jusqu’aux expériences des utilisateurs finaux. Ces investissements approfondis continuent et, aujourd’hui, plus de 3 500 ingénieurs Microsoft sont engagés dans la création et l’amélioration de la pile de sécurité de Microsoft et s’occupent de manière proactive du paysage des menaces qui changent. Avec des milliards d’ordinateurs, des billions de connexions et d’innombrables zettaoctets d’informations confiés à la protection de Microsoft, l’entreprise possède désormais la pile de sécurité la plus avancée dans l’industrie technologique et est largement considéré comme le leader mondial dans la lutte contre les acteurs malveillants.

Power BI repose sur cette base forte. Elle utilise la même pile de sécurité qui a gagné le droit d’Azure de servir et de protéger les données les plus sensibles au monde, et elle s’intègre aux outils de protection et de conformité des informations les plus avancés de Microsoft 365. En plus de cela, il assure la sécurité grâce à des mesures de sécurité multicouches, ce qui entraîne une protection de bout en bout conçue pour relever les défis uniques de l’ère cloud.

Pour fournir une solution de bout en bout pour protéger les ressources sensibles, l’équipe produit a besoin de résoudre les problèmes des clients difficiles sur plusieurs fronts simultanés :

  • Comment contrôler qui peut se connecter, où ils se connectent et comment ils se connectent ?Comment pouvons-nous contrôler les connexions ?
  • Comment les données sont-elles stockées ?Comment est-il chiffré ?Quels contrôles ai-je sur mes données ?
  • Comment contrôler et protéger mes données sensibles ?Comment vérifier que ces données ne peuvent pas être divulguées en dehors de l’organisation ?
  • Comment puis-je auditer qui effectue les opérations ?Comment réagir rapidement en cas d’activité suspecte sur le service ?

Cet article fournit une réponse complète à toutes ces questions. Il commence par une vue d’ensemble de l’architecture de service et explique comment fonctionnent les principaux flux dans le système. Il passe ensuite à la description de la façon dont les utilisateurs s’authentifient auprès de Power BI, comment les connexions de données sont établies et comment Power BI stocke et déplace les données via le service. La dernière section décrit les fonctionnalités de sécurité qui vous permettent, en tant qu’administrateur de service, de protéger vos ressources les plus précieuses.

Le service Power BI est régi par les conditions des services en ligne Microsoft et la déclaration de confidentialité de Microsoft Enterprise. Pour connaître l’emplacement du traitement des données, reportez-vous à l’emplacement des termes de traitement des données dans les conditions des services en ligne Microsoft et à l’addenda sur la protection des données. Pour les informations de conformité, le Centre de gestion de la confidentialité Microsoft est la ressource principale pour Power BI. L’équipe Power BI travaille dur pour apporter à ses clients les dernières innovations et productivité. En savoir plus sur la conformité dans les offres de conformité Microsoft.

Le service Power BI suit le cycle de vie du développement de la sécurité (SDL), des pratiques de sécurité strictes qui prennent en charge les exigences d’assurance et de conformité de la sécurité. Le SDL aide les développeurs à créer des logiciels plus sécurisés en réduisant le nombre et la gravité des vulnérabilités des logiciels, tout en réduisant les coûts de développement. Pour en savoir plus, consultez Pratiques de cycle de vie du développement de la sécurité Microsoft.

Architecture de Power BI

Le service Power BI repose sur azure, la plateforme cloud computing de Microsoft. Power BI est actuellement déployé dans de nombreux centres de données du monde entier ; il existe de nombreux déploiements actifs mis à la disposition des clients dans les régions desservies par ces centres de données et un nombre égal de déploiements passifs qui servent de sauvegardes pour chaque déploiement actif.

WFE et arrière-plan

Cluster web frontal (WFE)

Le cluster frontal web (WFE) fournit au navigateur de l’utilisateur le contenu initial de la page HTML lors du chargement du site. Il inclut également des pointeurs vers le contenu du réseau de distribution de contenu (CDN) Azure utilisé pour afficher le site dans le navigateur.

The WEF Cluster

Un cluster WFE se compose d’un site web ASP.NET s’exécutant dans l’environnement Azure App Service. Lorsque les utilisateurs tentent de se connecter au service Power BI, le service DNS du client peut communiquer avec Azure Traffic Manager pour trouver le centre de données le plus approprié (généralement le plus proche) avec un déploiement Power BI. Pour plus d’informations sur ce processus, consultez la méthode de routage du trafic de performances pour Azure Traffic Manager.

Les ressources statiques telles que *.js, *.css et les fichiers image sont principalement stockés sur un CDN Azure et récupérés directement par le navigateur. Notez que les déploiements de cluster Sovereign Government sont une exception à cette règle et, pour des raisons de conformité, omettront le CDN et utiliseront plutôt un cluster WFE à partir d’une région conforme pour héberger du contenu statique.

Cluster de back-end Power BI

Le cluster principal est l’épine dorsale de toutes les fonctionnalités disponibles dans Power BI. Il se compose de plusieurs points de terminaison de service consommés par les clients WFE et API, ainsi que des services de travail en arrière-plan, des bases de données, des caches et différents autres composants.

Le serveur principal est disponible dans la plupart des régions Azure et est déployé dans de nouvelles régions dès qu’ils deviennent disponibles. Une seule région Azure héberge un ou plusieurs clusters principaux qui autorisent une mise à l’échelle horizontale illimitée du service Power BI une fois que les limites de mise à l’échelle verticale et horizontale d’un seul cluster sont épuisées.

Chaque cluster back-end est avec état et héberge toutes les données de tous les locataires affectés à ce cluster. Un cluster qui contient les données d’un locataire spécifique est appelé cluster d’accueil du locataire. Les informations du cluster d'accueil d'un utilisateur authentifié sont fournies par le Service Global et utilisées par le WFE pour acheminer les demandes vers le cluster d'accueil du locataire.

Chaque cluster principal se compose de plusieurs machines virtuelles combinées en plusieurs groupes identiques redimensionnables paramétrés pour effectuer des tâches spécifiques, des ressources avec état telles que des bases de données SQL, des comptes de stockage, des bus de service, des caches et d’autres composants cloud nécessaires.

Les métadonnées de locataire et les données sont stockées dans les limites du cluster, à l’exception de la réplication des données vers un cluster back-end secondaire dans une région Azure jumelée dans la même zone géographique Azure. Le cluster principal secondaire sert de cluster de basculement en cas de panne régionale et est passif à tout autre moment.

Les fonctionnalités principales sont prises en charge par les microservices s’exécutant sur différents ordinateurs du réseau virtuel du cluster qui ne sont pas accessibles à partir de l’extérieur, à l’exception de deux composants accessibles à partir de l’Internet public :

  • Service de passerelle
  • Gestion des API Azure

Cluster d'infrastructure

Infrastructure Premium de Power BI

Power BI Premium offre un service pour les abonnés qui nécessitent des fonctionnalités Power BI Premium, telles que l’IA avancée, la distribution aux utilisateurs non autorisés, etc. Lorsqu’un client s’inscrit à un abonnement Power BI Premium, la capacité Premium est créée via Azure Resource Manager.

Les capacités Power BI Premium sont hébergées dans des clusters back-end indépendants du back-end Power BI standard, comme décrit ci-dessus. Cela offre une meilleure isolation, allocation des ressources, capacité de support, isolation de la sécurité et évolutivité de l’offre Premium.

Le diagramme suivant illustre l’architecture de l’infrastructure Power BI Premium :

Power BI Premium

La connexion à l’infrastructure Power BI Premium peut être effectuée de plusieurs façons, en fonction du scénario utilisateur. Les clients Power BI Premium peuvent être le navigateur d’un utilisateur, un back-end Power BI standard, des connexions directes via des clients XMLA, des API ARM, etc.

L’infrastructure Power BI Premium dans une région Azure se compose de plusieurs clusters Power BI Premium (le minimum est un). La plupart des ressources Premium sont encapsulées à l’intérieur d’un cluster (par exemple, le calcul) et certaines ressources régionales courantes (par exemple, le stockage de métadonnées). L’infrastructure Premium permet d’atteindre une scalabilité horizontale dans une région : augmenter les ressources à l’intérieur des clusters et/ou ajouter davantage de clusters à la demande si nécessaire (si les ressources de cluster approchent de leurs limites).

La colonne principale de chaque cluster est la gestion des ressources de calcul par virtual Machine Scale Sets et Azure Service Fabric. Les jeux de mises à l'échelle des machines virtuelles et Service Fabric permettent une augmentation rapide et sans douleur des nœuds de calcul à mesure que l'utilisation augmente, et orchestrent le déploiement, la gestion et la surveillance des services et applications Power BI Premium.

Il existe de nombreuses ressources environnantes qui garantissent une infrastructure sécurisée et fiable : équilibreurs de charge, réseaux virtuels, groupes de sécurité réseau, service bus, stockage, etc. Tous les secrets, clés et certificats requis pour Power BI Premium sont gérés exclusivement par Azure Key Vault . Toute authentification est effectuée via l’intégration à l’ID Microsoft Entra exclusivement.

Toute demande qui vient à l’infrastructure Power BI Premium passe d’abord aux nœuds frontaux : il s’agit des seuls nœuds disponibles pour les connexions externes. Les autres ressources sont masquées derrière les réseaux virtuels. Les nœuds frontaux authentifient la requête, la gèrent ou la transfèrent aux ressources appropriées (par exemple, les nœuds principaux).

Les nœuds back-end fournissent la plupart des capacités et fonctionnalités de Power BI Premium.

Power BI Mobile

Power BI Mobile est une collection d’applications conçues pour les trois plateformes mobiles principales : Android, iOS et Windows (UWP). Les considérations de sécurité pour les applications Power BI Mobile se répartissent en deux catégories :

  • Communication de l’appareil
  • Application et données sur l’appareil

Pour la communication des appareils, toutes les applications Power BI Mobile communiquent avec le service Power BI et utilisent les mêmes séquences de connexion et d’authentification utilisées par les navigateurs, qui sont décrites en détail plus haut dans ce livre blanc. Les applications mobiles Power BI pour iOS et Android affichent une session de navigateur au sein de l’application elle-même, tandis que l’application mobile Windows affiche un répartiteur pour établir le canal de communication avec Power BI (pour le processus de connexion).

Le tableau suivant présente la prise en charge de l’authentification basée sur les certificats (CBA) pour Power BI Mobile, en fonction de la plateforme d’appareils mobiles :

Prise en charge de CBA Ios Android Fenêtres
Power BI (connexion au service) Soutenu Soutenu Non prise en charge
SSRS ADFS local (se connecter au serveur SSRS) Non prise en charge Soutenu Non prise en charge
Proxy d’application SSRS Soutenu Soutenu Non prise en charge

Les applications Power BI Mobile communiquent activement avec le service Power BI. La télémétrie est utilisée pour collecter les statistiques d’utilisation des applications mobiles et des données similaires, qui sont transmises aux services utilisés pour surveiller l’utilisation et l’activité ; aucune donnée client n’est envoyée avec la télémétrie.

L’application Power BI stocke les données sur l’appareil qui facilitent l’utilisation de l’application :

  • Les jetons d’identification et d’actualisation Microsoft Entra sont stockés dans un mécanisme sécurisé sur l’appareil, à l’aide de mesures de sécurité standard.
  • Les données et les paramètres (paires clé-valeur pour la configuration utilisateur) sont mis en cache dans le stockage sur l’appareil et peuvent être chiffrés par le système d’exploitation. Dans iOS, cette opération est effectuée automatiquement lorsque l’utilisateur définit un code secret. Dans Android, vous pouvez le configurer dans les paramètres. Dans Windows, elle s’effectue à l’aide de BitLocker.
  • Pour les applications Android et iOS, les données et les paramètres (paires clé-valeur pour la configuration utilisateur) sont mis en cache dans le stockage sur l’appareil dans un bac à sable et un stockage interne accessible uniquement à l’application.
  • La géolocalisation est activée ou désactivée explicitement par l’utilisateur. Si elle est activée, les données de géolocalisation ne sont pas enregistrées sur l’appareil et ne sont pas partagées avec Microsoft.
  • Les notifications sont activées ou désactivées explicitement par l’utilisateur. Si cette option est activée, Android et iOS ne prennent pas en charge les exigences de stockage géographique des données pour les notifications.

Le chiffrement des données peut être amélioré en appliquant le chiffrement au niveau des fichiers via Microsoft Intune, un service logiciel qui fournit une gestion des appareils mobiles et des applications. Les trois plateformes pour lesquelles Power BI Mobile est disponible prennent en charge Intune. Avec Intune activé et configuré, les données sur l’appareil mobile sont chiffrées et l’application Power BI elle-même ne peut pas être installée sur une carte SD. En savoir plus sur Microsoft Intune.

L’application Windows prend également en charge la protection des informations Windows (WIP).

Pour implémenter l’authentification unique, certaines valeurs de stockage sécurisées liées à l’authentification basée sur les jetons sont disponibles pour d’autres applications internes Microsoft (telles que Microsoft Authenticator) et gérées par la bibliothèque d’authentification Microsoft (MSAL).

Les données mises en cache Power BI Mobile sont supprimées lorsque l’application est supprimée, lorsque l’utilisateur se déconnecte de Power BI Mobile ou lorsque l’utilisateur ne parvient pas à se connecter (par exemple, après un événement d’expiration de jeton ou une modification du mot de passe). Le cache de données comprend des tableaux de bord et des rapports précédemment accessibles à partir de l’application Power BI Mobile.

Power BI Mobile n’accède pas à d’autres dossiers ou fichiers d’application sur l’appareil.

Les applications Power BI pour iOS et Android vous permettent de protéger vos données en configurant des identifications supplémentaires, telles que la fourniture de l’ID visage, de l’ID tactile ou d’un code secret pour iOS et des données biométriques (ID d’empreinte digitale) pour Android.

Authentification auprès du service Power BI

L’authentification utilisateur auprès du service Power BI se compose d’une série de requêtes, de réponses et de redirections entre le navigateur de l’utilisateur et le service Power BI ou les services Azure utilisés par Power BI. Cette séquence décrit le processus d’authentification utilisateur dans Power BI, qui suit le flux d’octroi de code d’authentification Microsoft Entra. Pour plus d’informations sur les options des modèles d’authentification utilisateur d’une organisation (modèles de connexion), consultez Choisir un modèle de connexion pour Microsoft 365.

Séquence d’authentification

La séquence d’authentification utilisateur pour le service Power BI se produit comme décrit dans les étapes suivantes, qui sont illustrées dans l’image qui les suit.

  1. Un utilisateur lance une connexion au service Power BI à partir d’un navigateur, soit en tapant l’adresse Power BI dans la barre d’adresses, soit en sélectionnant Se connecter à partir de la page marketing Power BI (https://powerbi.microsoft.com). La connexion est établie à l’aide de TLS et HTTPS, et toutes les communications suivantes entre le navigateur et le service Power BI utilisent HTTPS.

  2. Azure Traffic Manager vérifie l’enregistrement DNS de l’utilisateur pour déterminer le centre de données le plus approprié (généralement le plus proche) où Power BI est déployé et répond au DNS avec l’adresse IP du cluster WFE auquel l’utilisateur doit être envoyé.

  3. WFE retourne ensuite une page HTML au client de navigateur, qui contient une référence de bibliothèque MSAL.js nécessaire pour lancer le flux de connexion.

  4. Le client de navigateur charge la page HTML reçue du WFE et redirige l’utilisateur vers la page de connexion Microsoft Online Services.

  5. Une fois l’utilisateur authentifié, la page de connexion redirige l’utilisateur vers la page WFE Power BI avec un code d’authentification.

  6. Le client du navigateur charge la page HTML et utilise le code d’authentification pour demander des jetons (accès, ID, actualisation) à partir de l’ID Microsoft Entra.

  7. L’ID de locataire de l’utilisateur est utilisé par le client de navigateur pour interroger le service global Power BI, qui gère une liste de locataires et leurs emplacements de cluster principal Power BI. Le service global Power BI détermine quel cluster de service principal Power BI contient le locataire de l’utilisateur et retourne l’URL du cluster principal Power BI vers le client.

  8. Le client est désormais en mesure de communiquer avec l’API d’URL du cluster back-end Power BI, à l’aide du jeton d’accès dans l’en-tête d’autorisation pour les requêtes HTTP. Le jeton d’accès Microsoft Entra aura une date d’expiration définie conformément aux stratégies Microsoft Entra, et pour maintenir la session active, le client Power BI dans le navigateur de l’utilisateur effectue des demandes périodiques pour renouveler le jeton d’accès avant son expiration.

Diagramme illustrant la séquence d’authentification du client.

Dans les rares cas où l’authentification côté client échoue en raison d’une erreur inattendue, le code tente de revenir à l’utilisation de l’authentification côté serveur dans le WFE. Reportez-vous à la section questions et réponses à la fin de ce document pour plus d’informations sur le flux d’authentification côté serveur.

Résidence des données

Sauf indication contraire dans la documentation, Power BI stocke les données client dans une zone géographique Azure affectée lorsqu’un locataire Microsoft Entra s’inscrit pour la première fois aux services Power BI. Un locataire Microsoft Entra héberge les identités d’utilisateur et d’application, les groupes et d’autres informations pertinentes relatives à une organisation et à sa sécurité.

L’affectation d’une zone géographique Azure pour le stockage de données de locataire est effectuée en mappant le pays ou la région sélectionné dans le cadre de la configuration du locataire Microsoft Entra à la zone géographique Azure la plus appropriée où existe un déploiement Power BI. Une fois cette détermination effectuée, toutes les données clientEs Power BI sont stockées dans cette zone géographique Azure sélectionnée (également appelée géo-accueil), sauf dans les cas où les organisations utilisent des déploiements multigéographiques.

Zones géographiques multiples (multigéographiques)

Certaines organisations ont une présence globale et peuvent nécessiter des services Power BI dans plusieurs zones géographiques Azure. Par exemple, une entreprise peut avoir son siège social aux États-Unis, mais peut également faire des affaires dans d’autres zones géographiques, comme l’Australie. Dans ce cas, l’entreprise peut exiger que certaines données Power BI restent stockées au repos dans la région distante pour se conformer aux réglementations locales. Cette fonctionnalité du service Power BI est appelée multigéographique.

La couche d'exécution des requêtes, les caches de requêtes et les données d'artefacts attribuées à un espace de travail multi-géo sont hébergés et restent dans la zone géographique Azure à capacité distante. Toutefois, certaines métadonnées d’artefact, telles que la structure de rapport, peuvent rester stockées au repos dans la zone géographique du locataire. En outre, certains transits et traitement des données peuvent toujours se produire dans la zone géographique de base du locataire, même pour les espaces de travail hébergés dans une capacité Premium multigéographique.

Pour plus d’informations sur la création et la gestion de déploiements qui s’étendent sur plusieurs zones géographiques Azure, consultez Configurer la prise en charge multigéographique pour Fabric.

Régions et centres de données

Les services Power BI sont disponibles dans des zones géographiques Azure spécifiques, comme décrit dans le Centre de gestion de la confidentialité Microsoft. Pour plus d’informations sur l’emplacement de stockage de vos données et leur utilisation, reportez-vous au Centre de gestion de la confidentialité Microsoft. Les engagements concernant l’emplacement des données des clients au repos sont spécifiés dans les modalités relatives au traitement des données dans les Conditions d’utilisation de Microsoft Online Services.

Microsoft fournit également des centres de données pour les entités souveraines. Pour plus d’informations sur la disponibilité des services Power BI pour les clouds nationaux/régionaux, consultez clouds nationaux/régionaux Power BI.

Gestion des données

Cette section décrit les pratiques de gestion des données Power BI lorsqu’il s’agit de stocker, de traiter et de transférer des données client.

Données au repos

Power BI utilise deux types de ressources de stockage de données principaux :

  • Stockage Azure
  • Bases de données Azure SQL

Dans la plupart des scénarios, stockage Azure est utilisé pour conserver les données des artefacts Power BI, tandis que les bases de données Azure SQL sont utilisées pour conserver les métadonnées d’artefact.

Toutes les données persistantes par Power BI sont chiffrées par défaut à l’aide de clés gérées par Microsoft. Les données client stockées dans les bases de données Azure SQL sont entièrement chiffrées à l’aide de la technologie TDE (Transparent Data Encryption) d’Azure SQL . Les données client stockées dans stockage Blob Azure sont chiffrées à l’aide du chiffrement stockage Azure.

Si vous le souhaitez, les organisations peuvent utiliser Power BI Premium pour utiliser leurs propres clés pour chiffrer les données au repos importées dans un modèle sémantique. Cette approche est souvent décrite comme apportez votre propre clé (BYOK). L’utilisation de BYOK permet de s’assurer que même en cas d’erreur d’opérateur de service, les données client ne seront pas exposées , ce qui ne peut pas facilement être obtenu à l’aide du chiffrement côté service transparent. Pour plus d'informations, voir Apportez vos propres clés de chiffrement pour Power BI.

Les modèles sémantiques Power BI permettent différents modes de connexion de source de données qui déterminent si les données de source de données sont conservées dans le service ou non.

Mode de modèle sémantique (type) Données conservées dans Power BI
Importer Oui
Requête Directe Non
Live Connect Non
Matériau composite Si contient une source de données d’importation
Diffusion en continu S’il est configuré pour conserver

Quel que soit le mode de modèle sémantique utilisé, Power BI peut mettre temporairement en cache toutes les données récupérées pour optimiser les performances des requêtes et des rapports.

Données en cours de traitement

Les données sont traitées lorsqu’elles sont utilisées activement par un ou plusieurs utilisateurs dans le cadre d’un scénario interactif ou lorsqu’un processus en arrière-plan, tel que l’actualisation, touche ces données. Power BI charge activement les données traitées dans l’espace mémoire d’une ou plusieurs charges de travail de service. Pour faciliter les fonctionnalités requises par la charge de travail, les données traitées en mémoire ne sont pas chiffrées.

Données en transit

Power BI nécessite que tout le trafic HTTP entrant soit chiffré à l’aide de TLS 1.2 ou version ultérieure. Toutes les demandes tentant d’utiliser le service avec TLS 1.1 ou une version antérieure seront rejetées.

Authentification aux sources de données

Lors de la connexion à une source de données, un utilisateur peut choisir d’importer une copie des données dans Power BI ou de se connecter directement à la source de données.

Dans le cas de l’importation, un utilisateur établit une connexion en fonction de la connexion de l’utilisateur et accède aux données avec les informations d’identification. Une fois le modèle sémantique publié sur le service Power BI, Power BI utilise toujours les informations d’identification de cet utilisateur pour importer des données. Une fois les données importées, l’affichage des données dans les rapports et les tableaux de bord n’accède pas à la source de données sous-jacente. Power BI prend en charge l’authentification unique pour les sources de données sélectionnées. Si la connexion est configurée pour utiliser l’authentification unique, les informations d’identification du propriétaire du modèle sémantique sont utilisées pour se connecter à la source de données.

Si une source de données est connectée directement à l’aide d’informations d’identification préconfigurées, les informations d’identification préconfigurées sont utilisées pour se connecter à la source de données lorsqu’un utilisateur affiche les données. Si une source de données est connectée directement à l’aide de l’authentification unique, les informations d’identification de l’utilisateur actuel sont utilisées pour se connecter à la source de données lorsqu’un utilisateur affiche les données. Lorsqu’elle est utilisée avec l’authentification unique, la sécurité au niveau des lignes (RLS) et/ou la sécurité au niveau de l’objet (OLS) peuvent être implémentées sur la source de données. Cela permet aux utilisateurs d’afficher uniquement les données auxquels ils ont des privilèges d’accès. Lorsque la connexion est à des sources de données dans le cloud, l’authentification Microsoft Entra est utilisée pour l’authentification unique ; pour les sources de données locales, Kerberos, SECURITY Assertion Markup Language (SAML) et l’ID Microsoft Entra sont pris en charge.

Si la source de données est Azure Analysis Services ou Analysis Services local, et que le service RLS et/ou OLS est configuré, le service Power BI applique cette sécurité de niveau, et les utilisateurs qui n’ont pas suffisamment d’informations d’identification pour accéder aux données sous-jacentes (qui peuvent être une requête utilisée dans un tableau de bord, un rapport ou un autre artefact de données) ne voient pas les données dont ils n’ont pas suffisamment de privilèges.

Fonctionnalités Premium

Architecture des dataflows

Les dataflows permettent aux utilisateurs de configurer des opérations de traitement des données principales qui extraient des données à partir de sources de données polymorphes, d’exécuter une logique de transformation sur les données, puis de les placer dans un modèle cible pour une utilisation dans différentes technologies de présentation de rapports. Tout utilisateur disposant d’un rôle Membre, Contributeur ou Administrateur dans un espace de travail peut créer un flux de données. Les utilisateurs du rôle Visionneuse peuvent afficher les données traitées par le flux de données, mais peuvent ne pas apporter de modifications à sa composition. Une fois qu’un flux de données a été créé, tout membre, contributeur ou administrateur de l’espace de travail peut planifier des actualisations, ainsi qu’afficher et modifier le flux de données en prenant possession de celui-ci.

Chaque source de données configurée est liée à une technologie cliente pour accéder à cette source de données. La structure des informations d’identification requises pour y accéder est formée pour correspondre aux détails d’implémentation requis de la source de données. La logique de transformation est appliquée par les services Power Query pendant que les données sont en cours de vol. Pour les dataflows Premium, les services Power Query s’exécutent dans des nœuds principaux. Les données peuvent être extraites directement des sources cloud ou via une passerelle installée localement. Lorsqu’il est extrait directement d’une source cloud vers le service ou vers la passerelle, le transport utilise la méthodologie de protection spécifique à la technologie cliente, le cas échéant. Lorsque les données sont transférées de la passerelle vers le service cloud, elles sont chiffrées. Consultez la section Données en transit ci-dessus.

Lorsque les sources de données spécifiées par le client nécessitent des informations d’identification pour l’accès, le propriétaire/créateur du flux de données les fournira lors de la création. Ils sont stockés à l’aide du stockage d’informations d’identification standard à l’échelle du produit. Consultez Authentification pour les sources de données ci-dessus. Il existe différentes approches que les utilisateurs peuvent configurer pour optimiser la persistance et l’accès aux données. Par défaut, les données sont placées dans un compte de stockage protégé et appartenant à Power BI. Le chiffrement de stockage est activé sur les conteneurs de stockage Blob pour protéger les données à l'arrêt. Consultez Les données au repos ci-dessous. Toutefois, les utilisateurs peuvent configurer leur propre compte de stockage associé à leur propre abonnement Azure. Dans ce cas, un principal de service Power BI est autorisé à accéder à ce compte de stockage afin qu’il puisse y écrire les données pendant l’actualisation. Dans ce cas, le propriétaire de la ressource de stockage est responsable de la configuration du chiffrement sur le compte Azure Data Lake Storage configuré. Les données sont toujours transmises au stockage Blob à l’aide du chiffrement.

Étant donné que les performances lors de l’accès aux comptes de stockage peuvent ne pas être optimales pour certaines données, les utilisateurs ont également la possibilité d’utiliser un moteur de calcul hébergé par Power BI pour augmenter les performances. Dans ce cas, les données sont stockées de manière redondante dans une base de données SQL disponible pour DirectQuery via l’accès par le système Power BI principal. Les données sont toujours chiffrées sur le système de fichiers. Si l’utilisateur fournit une clé pour chiffrer les données stockées dans la base de données SQL, cette clé sera utilisée pour le chiffrer doublement.

Lors de l’interrogation à l’aide de DirectQuery, le protocole https de protocole de transport chiffré est utilisé pour accéder à l’API. Toute utilisation secondaire ou indirecte de DirectQuery est contrôlée par les mêmes contrôles d’accès précédemment décrits. Étant donné que les flux de données sont toujours liés à un espace de travail, l’accès aux données est toujours contrôlé par le rôle de l’utilisateur dans cet espace de travail. Un utilisateur doit avoir au moins un accès en lecture pour pouvoir interroger les données par n’importe quel moyen.

Lorsque Power BI Desktop est utilisé pour accéder aux données dans un flux de données, il doit d’abord authentifier l’utilisateur à l’aide de l’ID Microsoft Entra pour déterminer si l’utilisateur dispose de droits suffisants pour afficher les données. Dans ce cas, une clé SaS est acquise et utilisée pour accéder directement au stockage à l’aide du protocole de transport HTTPS chiffré.

Le traitement des données tout au long du pipeline émet des événements d’audit Office 365. Certains de ces événements capturent les opérations liées à la sécurité et à la confidentialité.

Rapports paginés

Les rapports paginés sont conçus pour être imprimés ou partagés. Ils sont appelés paginés parce qu’ils sont mis en forme pour s’adapter correctement à une page. Ils affichent toutes les données dans une table, même si la table s’étend sur plusieurs pages. Vous pouvez contrôler exactement la disposition de la page des rapports.

Les rapports paginés prennent en charge des expressions enrichies et puissantes rédigées en Microsoft Visual Basic .NET. Les expressions sont largement utilisées dans les rapports paginés du Générateur de rapports Power BI pour récupérer, calculer, afficher, grouper, trier, filtrer, paramétrer et mettre en forme des données.

Les expressions sont créées par l’auteur du rapport avec accès à la large gamme de fonctionnalités du .NET Framework. Le traitement et l’exécution des rapports paginés sont effectués à l’intérieur d’un bac à sable.

Les définitions de rapport paginés (.rdl) sont stockées dans Power BI, et pour publier et/ou afficher un rapport paginé, un utilisateur doit s’authentifier et autoriser de la même façon que décrit dans l’authentification auprès du service Power BI.

Le jeton Microsoft Entra obtenu pendant l’authentification est utilisé pour communiquer directement à partir du navigateur vers le cluster Power BI Premium.

Dans Power BI Premium, le runtime de service Power BI fournit un environnement d’exécution isolé approprié pour chaque rendu de rapport. Cela inclut les cas où les rapports rendus appartiennent aux espaces de travail affectés à la même capacité.

Un rapport paginé peut accéder à un large ensemble de sources de données dans le cadre du rendu du rapport. Le bac à sable ne communique pas directement avec les sources de données, mais communique plutôt avec le processus approuvé pour demander des données, puis le processus approuvé ajoute les informations d’identification requises à la connexion. De cette façon, le bac à sable n’a jamais accès à des informations d’identification ou à des secrets.

Pour prendre en charge des fonctionnalités telles que Bing Maps ou des appels à Azure Functions, le bac à sable a accès à Internet.

Power BI Embedded Analytics

Les fournisseurs de logiciels indépendants (ISV) et les fournisseurs de solutions ont deux modes principaux d’incorporation d’artefacts Power BI dans leurs applications web et portails : incorporer pour votre organisation et incorporer pour vos clients. L’artefact est incorporé dans un IFrame dans l’application ou le portail. Un IFrame n’est pas autorisé à lire ou écrire des données à partir de l’application web externe ou du portail, et la communication avec l’IFrame est effectuée à l’aide du Kit de développement logiciel (SDK) client Power BI à l’aide de messages POST.

Dans un scénario en intégration pour votre organisation, les utilisateurs de Microsoft Entra accèdent à leur propre contenu Power BI via des portails personnalisés par leurs entreprises et leurs services informatiques. Toutes les stratégies et fonctionnalités Power BI décrites dans ce document, telles que RLS et OLS, sont automatiquement appliquées à tous les utilisateurs indépendamment de l’accès à Power BI via le portail Power BI ou via des portails personnalisés.

Dans un scénario d'intégration pour vos clients, les fournisseurs de logiciels indépendants possèdent généralement des locataires Power BI et des éléments Power BI (tableaux de bord, rapports, modèles sémantiques et autres). Il incombe à un service principal ISV d’authentifier ses utilisateurs finaux et de décider quels artefacts et quel niveau d’accès convient à cet utilisateur final. Les décisions de stratégie ISV sont chiffrées dans un jeton incorporé généré par Power BI et transmis au back-end ISV pour une distribution supplémentaire aux utilisateurs finaux en fonction de la logique métier de l’ISV. Les utilisateurs finaux utilisant un navigateur ou d’autres applications clientes ne peuvent pas déchiffrer ou modifier des jetons incorporés. Les SDK côté client, tels que les API clients Power BI, ajoutent automatiquement le jeton incorporé chiffré aux requêtes Power BI comme un en-tête d'autorisation : EmbedToken. En fonction de cet en-tête, Power BI appliquera toutes les stratégies (telles que l'accès ou la sécurité au niveau de la ligne (RLS)) précisément telles que spécifiées par l'ISV (fournisseur de logiciels indépendants) pendant la génération.

Pour activer l’incorporation et l’automatisation, et pour générer les jetons incorporés décrits ci-dessus, Power BI expose un ensemble complet d’API REST. Ces API REST Power BI prennent en charge les méthodes d’authentification et d’autorisation Microsoft Entra déléguées par l’utilisateur et le principal de service .

L’analytique incorporée Power BI et ses API REST prennent en charge toutes les fonctionnalités d’isolation réseau Power BI décrites dans cet article, notamment les balises de service etles liaisons privées.

Fonctionnalités d’IA

Power BI prend actuellement en charge deux grandes catégories de fonctionnalités d’IA dans le produit aujourd’hui : les visuels IA et les enrichissements d’IA. Les fonctionnalités IA au niveau visuel incluent des capacités telles que les influenceurs clés, l’arborescence de décomposition, la narration intelligente, la détection d’anomalies, les visuels R et Python, le clustering, la prévision, le Q&A, les insights rapides, etc. Les capacités d’enrichissement par IA incluent AutoML, Azure Machine Learning, les services cognitifs, et les transformations R/Python, etc.

La plupart des fonctionnalités mentionnées ci-dessus sont prises en charge dans les espaces de travail Partagés et Premium aujourd’hui. Toutefois, AutoML et CognitiveServices sont pris en charge uniquement dans les espaces de travail Premium, en raison de restrictions IP. Aujourd’hui, avec l’intégration AutoML dans Power BI, un utilisateur peut créer et entraîner un modèle Machine Learning personnalisé (ML) (par exemple, Prédiction, Classification, Régression, etc.) et l’appliquer pour obtenir des prédictions lors du chargement de données dans un flux de données défini dans un espace de travail Premium. En outre, les utilisateurs de Power BI peuvent appliquer plusieurs API CognitiveServices, telles que TextAnalytics et ImageTagging, pour transformer des données avant de les charger dans un modèle dataflow/sémantique défini dans un espace de travail Premium.

Les fonctionnalités d’enrichissement d’IA Premium peuvent être mieux vues sous la forme d’une collection de fonctions/transformations IA sans état qui peuvent être utilisées par les utilisateurs Power BI dans leurs pipelines d’intégration de données utilisés par un modèle sémantique Power BI ou un dataflow. Notez que ces fonctions sont également accessibles à partir d’environnements de création de modèles de flux de données/sémantique actuels dans le service Power BI et Power BI Desktop. Ces fonctions/transformations IA s’exécutent toujours dans un espace de travail/capacité Premium. Ces fonctions sont exposées dans Power BI en tant que source de données qui nécessite un jeton Microsoft Entra pour l’utilisateur Power BI qui utilise la fonction IA. Ces sources de données IA sont spéciales, car elles ne présentent aucune de leurs propres données et fournissent uniquement ces fonctions/transformations. Pendant l’exécution, ces fonctionnalités n’effectuent aucun appel sortant à d’autres services pour transmettre les données du client. Examinons les scénarios Premium individuellement pour comprendre les modèles de communication et les détails relatifs à la sécurité pertinents qui leur sont associés.

Pour l’entraînement et l’application d’un modèle AutoML, Power BI utilise le Kit de développement logiciel (SDK) Azure AutoML et exécute toutes les formations dans la capacité Power BI du client. Pendant les itérations d’entraînement, Power BI appelle un service Azure Machine Learning d’expérimentation pour sélectionner un modèle et des hyper-paramètres appropriés pour l’itération actuelle. Dans cet appel sortant, seules les métadonnées d’expérience pertinentes (par exemple, précision, algorithme ml, paramètres d’algorithme, etc.) de l’itération précédente sont envoyées. L’apprentissage AutoML produit un modèle ONNX et des données de rapport d’entraînement qui sont ensuite enregistrées dans le flux de données. Plus tard, les utilisateurs de Power BI peuvent ensuite appliquer le modèle ML entraîné en tant que transformation pour opérationnaliser le modèle ML selon une planification. Pour les API TextAnalytics et ImageTagging, Power BI n’appelle pas directement les API du service CognitiveServices, mais utilise plutôt un SDK interne pour exécuter les API dans la capacité Power BI Premium. Aujourd’hui, ces API sont prises en charge dans les dataflows Power BI et les modèles sémantiques. Lors de la création d’un modèle de données dans Power BI Desktop, les utilisateurs peuvent uniquement accéder à cette fonctionnalité s’ils ont accès à un espace de travail Power BI Premium. Par conséquent, les clients sont invités à fournir leurs informations d’identification Microsoft Entra.

Isolement réseau

Cette section décrit les fonctionnalités de sécurité avancées dans Power BI. Certaines des fonctionnalités ont des exigences spécifiques en matière de licence. Pour plus d’informations, consultez les sections ci-dessous.

Balises de service

Une étiquette de service représente un groupe de préfixes d’adresses IP d’un service Azure donné. Il permet de réduire la complexité des mises à jour fréquentes des règles de sécurité réseau. Les clients peuvent utiliser des balises de service pour définir des contrôles d’accès réseau sur des groupes de sécurité réseau ou un pare-feu Azure. Les clients peuvent utiliser des balises de service à la place d’adresses IP spécifiques lors de la création de règles de sécurité. En spécifiant le nom de l’étiquette de service (par exemple PowerBI) dans le champ source ou destination approprié (pour les API) d’une règle, les clients peuvent autoriser ou refuser le trafic pour le service correspondant. Microsoft gère les préfixes d’adresses englobés par la balise de service et met automatiquement à jour la balise de service à mesure que les adresses changent.

La mise en réseau Azure fournit la fonctionnalité Azure Private Link qui permet à Power BI de fournir un accès sécurisé via des points de terminaison privés de mise en réseau Azure. Avec Azure Private Link et les points de terminaison privés, le trafic de données est envoyé en privé à l’aide de l’infrastructure réseau principale de Microsoft, et les données ne transitent donc pas par Internet.

Private Link garantit que les utilisateurs de Power BI utilisent la colonne principale du réseau privé Microsoft lors de l’accès aux ressources dans le service Power BI.

L’utilisation de Private Link avec Power BI offre les avantages suivants :

  • Private Link garantit que le trafic transite sur le réseau principal Azure vers un point de terminaison privé pour les ressources cloud Azure.
  • L’isolation du trafic réseau à partir d’une infrastructure non basée sur Azure, telle que l’accès local, exigerait que les clients aient configuré ExpressRoute ou un VPN.

Pour plus d’informations, consultez les liens privés pour obtenir un accès sécurisé à Fabric .

Connectivité au réseau virtuel

Bien que la fonctionnalité d’intégration private Link fournit des connexions entrantes sécurisées à Power BI, la fonctionnalité de connectivité de réseau virtuel permet une connectivité sortante sécurisée de Power BI vers des sources de données au sein d’un réseau virtuel.

Les passerelles de réseau virtuel (gérées par Microsoft) éliminent la surcharge liée à l’installation et à la surveillance des passerelles de données locales pour la connexion à des sources de données associées à un réseau virtuel. Toutefois, ils suivent toujours le processus familier de gestion de la sécurité et des sources de données, comme avec une passerelle de données locale.

Voici une vue d’ensemble de ce qui se passe quand vous interagissez avec un rapport Power BI connecté à une source de données au sein d’un réseau virtuel à l’aide de passerelles de réseau virtuel :

  1. Le service cloud Power BI (ou l’un des autres services cloud pris en charge) lance une requête et envoie la requête, les détails de la source de données et les informations d’identification au service de réseau virtuel Power Platform (PP VNet).

  2. Le service de réseau virtuel PP injecte ensuite en toute sécurité un conteneur exécutant une passerelle de réseau virtuel dans le sous-réseau. Ce conteneur peut désormais se connecter aux services de données accessibles à partir de ce sous-réseau.

  3. Le service de réseau virtuel PP envoie ensuite la requête, les détails de la source de données et les informations d’identification à la passerelle de réseau virtuel.

  4. La passerelle de réseau virtuel obtient la requête et se connecte aux sources de données avec ces informations d’identification.

  5. La requête est ensuite envoyée à la source de données pour l’exécution.

  6. Après l’exécution, les résultats sont envoyés à la passerelle de réseau virtuel, et le service de réseau virtuel PP envoie en toute sécurité les données du conteneur au service cloud Power BI.

Principaux de service

Power BI prend en charge l’utilisation des principaux de service. Stockez les informations d’identification du principal de service utilisées pour chiffrer ou accéder à Power BI dans un coffre de clés, attribuer des stratégies d’accès appropriées au coffre et examiner régulièrement les autorisations d’accès.

Pour plus d’informations, consultez Automatiser l’espace de travail Premium et les tâches de modèle sémantique avec des principaux de service .

Microsoft Purview pour Power BI

Protection des informations de Microsoft Purview

Power BI est profondément intégré à Microsoft Purview Information Protection. Microsoft Purview Information Protection permet aux organisations d’avoir une solution unique et intégrée pour la classification, l’étiquetage, l’audit et la conformité dans Azure, Power BI et Office.

Lorsque la protection des informations est activée dans Power BI :

  • Les données sensibles, tant dans le service Power BI que dans Power BI Desktop, peuvent être classifiées et étiquetées à l’aide des mêmes étiquettes de confidentialité utilisées dans Office et dans Azure.
  • Les stratégies de gouvernance peuvent être appliquées lorsque le contenu Power BI est exporté vers des fichiers Excel, PowerPoint, PDF, Word ou .pbix , pour vous assurer que les données sont protégées même lorsqu’elles quittent Power BI.
  • Il est facile de classifier et de protéger les fichiers .pbix dans Power BI Desktop, comme dans les applications Excel, Word et PowerPoint. Les fichiers peuvent être facilement étiquetés en fonction de leur niveau de confidentialité. De plus, ils peuvent être chiffrés s’ils contiennent des données confidentielles pour l’entreprise, ce qui garantit que seuls les utilisateurs autorisés peuvent modifier ces fichiers.
  • Les classeurs Excel héritent automatiquement des labels de sensibilité lorsqu’ils se connectent à Power BI, ce qui permet de maintenir la classification de bout en bout et d’appliquer la protection lorsque les modèles sémantiques Power BI sont analysés dans Excel.
  • Les étiquettes de confidentialité appliquées aux rapports et tableaux de bord Power BI sont visibles dans les applications mobiles Power BI iOS et Android.
  • Les étiquettes de confidentialité persistent lorsqu’un rapport Power BI est incorporé dans Teams, SharePoint ou un site web sécurisé. Cela permet aux organisations de maintenir la classification et la protection lors de l’exportation lors de l’incorporation de contenu Power BI.
  • L’héritage des étiquettes lors de la création de contenu dans le service Power BI garantit que les étiquettes appliquées aux modèles sémantiques ou aux datamarts du service Power BI seront appliquées au nouveau contenu créé en plus de ces modèles sémantiques et de ces datamarts.
  • Les API d’analyse d’administration Power BI peuvent extraire l’étiquette de confidentialité d’un élément Power BI, ce qui permet aux administrateurs Power BI et InfoSec de surveiller l’étiquetage dans le service Power BI et de produire des rapports exécutifs.
  • Les API d’administration Power BI permettent aux équipes centrales d’appliquer par programmation des étiquettes de confidentialité au contenu du service Power BI.
  • Les équipes centrales peuvent créer des stratégies d’étiquettes obligatoires pour appliquer des étiquettes sur du contenu nouveau ou modifié dans Power BI.
  • Les équipes centrales peuvent créer des stratégies d’étiquette par défaut pour s’assurer qu’une étiquette de confidentialité est appliquée à tout contenu Power BI nouveau ou modifié.
  • L'étiquetage automatique de sensibilité en aval dans le service Power BI garantit que lorsqu'une étiquette sur un modèle sémantique ou un datamart est appliquée ou modifiée, l'étiquette est automatiquement appliquée ou modifiée sur tout le contenu en aval connecté au modèle sémantique ou au datamart.

Pour plus d’informations, consultez Étiquettes de confidentialité dans Power BI.

Stratégies de protection contre la perte de données (DLP) Microsoft Purview pour Power BI

Les stratégies de protection contre la perte de données (DLP) de Microsoft Purview aident les organisations à réduire le risque de fuite de données métier sensibles à partir de Power BI. Les stratégies DLP les aident à respecter les exigences de conformité des réglementations gouvernementales ou sectorielles et à s’assurer que leurs données dans Power BI sont gérées.

Lorsque les stratégies DLP pour Power BI sont configurées :

  • Tous les modèles sémantiques dans les espaces de travail spécifiés dans la stratégie sont évalués par la stratégie.
  • Vous pouvez détecter quand des données sensibles sont chargées dans vos capacités Premium. Les stratégies DLP peuvent détecter :
    • Étiquettes de sensibilité.
    • Types d’informations sensibles. Plus de 260 types sont pris en charge. La détection de type d’informations sensibles s’appuie sur l’analyse de contenu Microsoft Purview.
  • Lorsque vous rencontrez un modèle sémantique identifié comme sensible, vous pouvez voir un conseil de stratégie personnalisé qui vous aide à comprendre ce que vous devez faire.
  • Si vous êtes propriétaire d’un modèle sémantique, vous pouvez remplacer une stratégie et empêcher votre modèle sémantique d’être identifié comme « sensible » si vous avez une raison valide de le faire.
  • Si vous êtes propriétaire d’un modèle sémantique, vous pouvez signaler un problème avec une stratégie si vous concluez qu’un type d’informations sensibles a été identifié faussement.
  • Les atténuations automatiques des risques, telles que les alertes à l’administrateur de sécurité, peuvent être appelées.

Pour plus d’informations, consultez les stratégies de protection contre la perte de données pour Fabric et Power BI.

Microsoft Defender pour les applications cloud pour Power BI

Microsoft Defender pour Cloud Apps est l’un des principaux répartiteurs de sécurité d’accès cloud du monde, nommé leader dans le Magic Quadrant de Gartner pour le marché du répartiteur de sécurité d’accès au cloud (CASB). Defender pour Cloud Apps est utilisé pour sécuriser l’utilisation d’applications cloud. Il permet aux organisations de surveiller et de contrôler, en temps réel, des sessions Power BI risquées telles que l’accès utilisateur à partir d’appareils non gérés. Les administrateurs de sécurité peuvent définir des stratégies pour contrôler les actions des utilisateurs, telles que le téléchargement de rapports avec des informations sensibles.

Avec Defender pour Cloud Apps, les organisations peuvent bénéficier des fonctionnalités DLP suivantes :

  • Définissez des contrôles en temps réel pour appliquer des sessions utilisateur risquées dans Power BI. Par exemple, si un utilisateur se connecte à Power BI à partir de l’extérieur de son pays ou de sa région, la session peut être surveillée par les contrôles defender pour cloud Apps en temps réel et les actions risquées, telles que le téléchargement de données marquées avec une étiquette de confidentialité « Hautement confidentiel », peuvent être bloquées immédiatement.
  • Examinez l’activité de l’utilisateur Power BI avec le journal d’activité Defender for Cloud Apps. Le journal d’activité Defender for Cloud Apps inclut l’activité Power BI comme capturée dans le journal d’audit Office 365, qui contient des informations sur toutes les activités utilisateur et administrateur, ainsi que des informations d’étiquette de sensibilité pour les activités telles que l’application, la modification et la suppression d’étiquettes. Les administrateurs peuvent tirer parti des filtres avancés Defender pour Cloud Apps et des actions rapides pour une investigation efficace des problèmes.
  • Créez des stratégies personnalisées pour alerter sur l’activité suspecte de l’utilisateur dans Power BI. La fonctionnalité de stratégie d’activité Defender pour Cloud Apps peut être exploitée pour définir vos propres règles personnalisées, pour vous aider à détecter le comportement de l’utilisateur qui s’écarte de la norme, et même éventuellement agir automatiquement, s’il semble trop dangereux.
  • Collaborez avec la détection d’anomalie intégrée de Defender pour Cloud Apps. Les stratégies de détection des anomalies Defender pour Cloud Apps fournissent une analytique comportementale utilisateur prête à l’emploi et un machine learning afin que vous soyez prêt dès le départ à exécuter une détection avancée des menaces dans votre environnement cloud. Lorsqu’une stratégie de détection d’anomalie identifie un comportement suspect, elle déclenche une alerte de sécurité.
  • Rôle d’administrateur Power BI dans le portail Defender for Cloud Apps. Defender pour Cloud Apps fournit un rôle d’administrateur spécifique à l’application qui peut être utilisé pour accorder aux administrateurs Power BI uniquement les autorisations dont ils ont besoin pour accéder aux données pertinentes de Power BI dans le portail, telles que les alertes, les utilisateurs à risque, les journaux d’activité et d’autres informations relatives à Power BI.

Pour plus d’informations, consultez Utilisation des contrôles Microsoft Defender pour Cloud Apps dans Power BI.

Questions et réponses relatives à la sécurité Power BI

Les questions suivantes sont des questions de sécurité courantes et des réponses pour Power BI. Ils sont organisés en fonction du moment où ils ont été ajoutés à ce livre blanc, afin de faciliter votre capacité à trouver rapidement de nouvelles questions et réponses lorsque ce document est mis à jour. Les questions les plus récentes sont ajoutées à la fin de cette liste.

Comment les utilisateurs se connectent-ils et accèdent-ils aux sources de données lors de l’utilisation de Power BI ?

  • Power BI gère les informations d’identification aux sources de données pour chaque utilisateur pour les informations d’identification cloud ou pour la connectivité via une passerelle personnelle. Les sources de données gérées par une passerelle de données locale peuvent être partagées entre l’entreprise et les autorisations pour ces sources de données peuvent être gérées par l’administrateur de passerelle. Lors de la configuration d’un modèle sémantique, l’utilisateur est autorisé à sélectionner des informations d’identification à partir de son magasin personnel ou à utiliser une passerelle de données locale pour utiliser des informations d’identification partagées.

    Dans le cas d’importation, un utilisateur établit une connexion en fonction de la connexion de l’utilisateur et accède aux données avec les informations d’identification. Une fois le modèle sémantique publié sur le service Power BI, Power BI utilise toujours les informations d’identification de cet utilisateur pour importer des données. Une fois les données importées, l’affichage des données dans les rapports et les tableaux de bord n’accède pas à la source de données sous-jacente. Power BI prend en charge l’authentification unique pour les sources de données sélectionnées. Si la connexion est configurée pour utiliser l’authentification unique, les informations d’identification du propriétaire du modèle sémantique sont utilisées pour se connecter à la source de données.

    Pour les rapports connectés à DirectQuery, la source de données est connectée directement à l’aide d’informations d’identification préconfigurées. Les informations d’identification préconfigurées sont utilisées pour se connecter à la source de données lorsqu’un utilisateur affiche les données. Si une source de données est connectée directement à l’aide de l’authentification unique, les informations d’identification de l’utilisateur actuel sont utilisées pour se connecter à la source de données lorsque l’utilisateur affiche les données. Lorsque vous utilisez l’authentification unique, RLS et/ou OLS peuvent être implémentés sur la source de données, et cela permet aux utilisateurs d’afficher les données auxquels ils ont des privilèges d’accès. Lorsque la connexion est à des sources de données dans le cloud, l’authentification Microsoft Entra est utilisée pour l’authentification unique ; pour les sources de données locales, Kerberos, SAML et Microsoft Entra ID sont pris en charge.

    Lors de la connexion avec Kerberos, l'UPN de l'utilisateur est transmis à la passerelle, et en utilisant la délégation Kerberos contrainte, l'utilisateur est enregistré sous une identité empruntée et connecté aux sources de données respectives. SAML est également pris en charge sur la passerelle pour la source de données SAP HANA. Plus d’informations sont disponibles dans la vue d’ensemble de l’authentification unique pour les passerelles.

    Si la source de données est Azure Analysis Services ou Analysis Services local et RLS et/ou OLS est configurée, le service Power BI applique cette sécurité de niveau, et les utilisateurs qui n’ont pas suffisamment d’informations d’identification pour accéder aux données sous-jacentes (qui peuvent être une requête utilisée dans un tableau de bord, un rapport ou un autre artefact de données) ne voient pas les données pour lesquelles l’utilisateur ne dispose pas de privilèges suffisants.

    Les listes de révocation de certificats avec Power BI peuvent être utilisées pour restreindre l’accès aux données pour les utilisateurs donnés. Les filtres limitent l’accès aux données au niveau des lignes, et vous pouvez définir des filtres au sein d’un rôle.

    OLS peut être utilisé pour sécuriser des tables ou des colonnes sensibles. Toutefois, contrairement à RLS, OLS sécurise également les noms d’objets et les métadonnées. Cela permet d’empêcher les utilisateurs malveillants de découvrir même l’existence de ces objets. Les tables et colonnes sécurisées sont masquées dans la liste des champs lors de l’utilisation d’outils de création de rapports tels qu’Excel ou Power BI, et en outre, les utilisateurs sans autorisations ne peuvent pas accéder aux objets de métadonnées sécurisés via DAX ou toute autre méthode. Du point de vue des utilisateurs sans autorisations d’accès appropriées, les tables et colonnes sécurisées n’existent pas.

    OLS, avec RLS, permet une sécurité améliorée au niveau de l’entreprise sur les rapports et les modèles sémantiques, ce qui garantit que seuls les utilisateurs disposant des autorisations requises ont accès à l’affichage et à l’interaction avec les données sensibles.

Comment les données sont-elles transférées vers Power BI ?

  • Toutes les données demandées et transmises par Power BI sont chiffrées en transit à l’aide du protocole HTTPS (sauf lorsque la source de données choisie par le client ne prend pas en charge HTTPS) pour se connecter à partir de la source de données au service Power BI. Une connexion sécurisée est établie avec le fournisseur de données, et une seule fois que cette connexion est établie, les données transitent par le réseau.

Comment Power BI met-il en cache les données de rapport, de tableau de bord ou de modèle, et est-ce sécurisé ?

Les clients cachent-ils localement les données de page web ?

  • Lorsque les clients du navigateur accèdent à Power BI, les serveurs web Power BI définissent la directive Cache-Control sur no-store. La directive no-store indique aux navigateurs de ne pas mettre en cache la page web en cours d’affichage par l’utilisateur et de ne pas stocker la page web dans le dossier de cache du client.

Qu’en est-il de la sécurité basée sur les rôles, du partage de rapports ou de tableaux de bord et des connexions de données ? Comment cela fonctionne-t-il en termes d’accès aux données, d’affichage de tableau de bord, d’accès aux rapports ou d’actualisation ?

  • Pour les sources de données non compatibles RLS , si un tableau de bord, un rapport ou un modèle de données est partagé avec d’autres utilisateurs via Power BI, les données sont ensuite disponibles pour les utilisateurs avec lesquels il est partagé pour afficher et interagir avec eux. Power BI ne réauthentique pas les utilisateurs par rapport à la source d’origine des données ; une fois que les données sont chargées dans Power BI, l’utilisateur qui s’est authentifié sur les données sources est responsable de la gestion des autres utilisateurs et groupes qui peuvent afficher les données.

    Lorsque des connexions de données sont établies à une source de données compatible avec la sécurité réseau, telle qu’une source de données Analysis Services, seules les données de tableau de bord sont mises en cache dans Power BI. Chaque fois qu’un rapport ou un modèle sémantique est affiché ou consulté dans Power BI qui utilise des données de la source de données compatible avec la sécurité réseau, le service Power BI accède à la source de données pour obtenir des données basées sur les informations d’identification de l’utilisateur et, si des autorisations suffisantes existent, les données sont chargées dans le rapport ou le modèle de données de cet utilisateur. Si l’authentification échoue, l’utilisateur voit une erreur.

    Pour plus d’informations, consultez Authentification aux sources de données.

Nos utilisateurs se connectent à toutes les mêmes sources de données, dont certains nécessitent des informations d’identification qui diffèrent de leurs informations d’identification de domaine. Comment peuvent-ils éviter d’avoir à entrer ces informations d’identification chaque fois qu’ils effectuent une connexion de données ?

Quels ports sont utilisés par une passerelle de données locale et une passerelle personnelle ? Existe-t-il des noms de domaine qui doivent être autorisés à des fins de connectivité ?

Lors de l’utilisation de la passerelle de données locale, comment les clés de récupération sont-elles utilisées et où sont-elles stockées ? Qu’en est-il de la gestion des informations d’identification sécurisées ?

  • Pendant l’installation et la configuration de la passerelle, l’administrateur saisit une clé de récupération de la passerelle. Cette clé de récupération est utilisée pour générer une clé symétrique AES forte. Une clé asymétrique RSA est également créée en même temps.

    Ces clés générées (RSA et AES) sont stockées dans un fichier situé sur l’ordinateur local. Ce fichier est également chiffré. Le contenu du fichier ne peut être déchiffré que par cet ordinateur Windows particulier, et uniquement par ce compte de service de passerelle particulier.

    Lorsqu’un utilisateur entre des informations d’identification de source de données dans l’interface utilisateur du service Power BI, les informations d’identification sont chiffrées avec la clé publique dans le navigateur. La passerelle déchiffre les informations d’identification à l’aide de la clé privée RSA et les chiffre à nouveau avec une clé symétrique AES avant que les données ne soient stockées dans le service Power BI. Avec ce processus, le service Power BI n’a jamais accès aux données non chiffrées.

Quels protocoles de communication sont utilisés par la passerelle de données locale et comment sont-ils sécurisés ?

  • La passerelle prend en charge les deux protocoles de communication suivants :

    • AMQP 1.0 – TCP + TLS : ce protocole nécessite que les ports 443, 5671-5672 et 9350-9354 soient ouverts pour la communication sortante. Ce protocole est préféré, car il a une surcharge de communication inférieure.

    • HTTPS : WebSockets sur HTTPS + TLS : ce protocole utilise uniquement le port 443. Le WebSocket est initié par un seul message HTTP CONNECT. Une fois le canal établi, la communication est essentiellement TCP+TLS. Vous pouvez forcer la passerelle à utiliser ce protocole en modifiant un paramètre décrit dans l’article sur la passerelle locale.

Quel est le rôle d’Azure CDN dans Power BI ?

  • Comme mentionné précédemment, Power BI utilise le CDN Azure pour distribuer efficacement le contenu statique et les fichiers nécessaires aux utilisateurs en fonction des paramètres régionaux géographiques. Pour aller plus loin, le service Power BI utilise plusieurs CDN pour distribuer efficacement le contenu statique et les fichiers nécessaires aux utilisateurs via l’Internet public. Ces fichiers statiques incluent des téléchargements de produits (tels que Power BI Desktop, la passerelle de données locale ou les applications Power BI à partir de différents éditeurs de logiciels indépendants), des fichiers de configuration de navigateur utilisés pour lancer et établir des connexions ultérieures avec le service Power BI, ainsi que la page de connexion Power BI sécurisée initiale.

    En fonction des informations fournies lors d’une connexion initiale au service Power BI, le navigateur d’un utilisateur contacte le CDN Azure spécifié (ou pour certains fichiers, le WFE) pour télécharger la collection de fichiers courants spécifiés nécessaires pour permettre l’interaction du navigateur avec le service Power BI. La page du navigateur inclut ensuite le jeton Microsoft Entra, les informations de session, l’emplacement du cluster back-end associé et la collection de fichiers téléchargés à partir du cdn Azure et du cluster WFE, pendant la durée de la session de navigateur du service Power BI.

Pour les visuels Power BI, Microsoft effectue-t-il une évaluation de la sécurité ou de la confidentialité du code visuel personnalisé avant de publier des éléments dans la galerie ?

  • Non. Il incombe au client de passer en revue et de déterminer si le code visuel personnalisé doit être utilisé. Tout le code visuel personnalisé est utilisé dans un environnement de bac à sable afin que tout code errant d’un visuel personnalisé n’affecte pas le reste du service Power BI.

Existe-t-il d’autres visuels Power BI qui envoient des informations en dehors du réseau client ?

  • Oui. Les visuels Bing Maps et ESRI transmettent des données hors du service Power BI pour les visuels qui utilisent ces services.

Pour les applications modèles, Microsoft effectue-t-il une évaluation de la sécurité ou de la confidentialité de l’application modèle avant de publier des éléments dans la galerie ?

  • Non. L’éditeur d’application est responsable du contenu alors qu’il incombe au client de passer en revue et de déterminer s’il faut approuver l’éditeur d’application modèle.

Existe-t-il des applications modèles qui peuvent envoyer des informations en dehors du réseau client ?

  • Oui. Il incombe au client de passer en revue la politique de confidentialité de l’éditeur et de déterminer s’il faut installer l’application modèle sur le locataire. L’éditeur est chargé d’informer le client sur le comportement et les fonctionnalités de l’application.

Qu’en est-il de la souveraineté des données ? Pouvons-nous approvisionner des locataires dans des centres de données situés dans des zones géographiques spécifiques, pour garantir que les données ne quittent pas les frontières du pays ou de la région ?

  • Certains clients de certaines zones géographiques ont la possibilité de créer un locataire dans un cloud national/régional, où le stockage et le traitement des données sont conservés séparément de tous les autres centres de données. Les clouds nationaux/régionaux ont un type de sécurité légèrement différent, car un administrateur de données distinct exploite le service Power BI cloud national/régional au nom de Microsoft.

    Les clients peuvent également configurer un locataire dans une région spécifique. Toutefois, ces locataires ne disposent pas d’un administrateur de données distinct de Microsoft. La tarification des clouds nationaux/régionaux diffère du service Power BI commercial généralement disponible. Pour plus d’informations sur la disponibilité des services Power BI pour les clouds nationaux/régionaux, consultez clouds nationaux/régionaux Power BI.

Comment Microsoft traite-t-il les connexions pour les clients qui ont des abonnements Power BI Premium ? Ces connexions sont-elles différentes de celles établies pour le service Power BI non Premium ?

  • Les connexions établies pour les clients disposant d’abonnements Power BI Premium implémentent un processus d’autorisation Microsoft Entra business-to-business (B2B), à l’aide de l’ID Microsoft Entra pour activer le contrôle d’accès et l’autorisation. Power BI gère les connexions des abonnés Power BI Premium aux ressources Power BI Premium, tout comme tout autre utilisateur Microsoft Entra.

Comment fonctionne l’authentification côté serveur dans le WFE ?

  • L’authentification de l'utilisateur côté service se déroule selon les étapes suivantes, illustrées par l'image qui les suit.

  1. Un utilisateur lance une connexion au service Power BI à partir d’un navigateur, soit en tapant l’adresse Power BI dans la barre d’adresses, soit en sélectionnant Se connecter à partir de la page marketing Power BI (https://powerbi.microsoft.com). La connexion est établie à l’aide de TLS 1.2 et HTTPS, et toutes les communications suivantes entre le navigateur et le service Power BI utilisent HTTPS.

  2. Azure Traffic Manager vérifie l’enregistrement DNS de l’utilisateur pour déterminer le centre de données le plus approprié (généralement le plus proche) où Power BI est déployé et répond au DNS avec l’adresse IP du cluster WFE auquel l’utilisateur doit être envoyé.

  3. WFE redirige ensuite l’utilisateur vers la page de connexion Microsoft Online Services.

  4. Une fois l’utilisateur authentifié, la page de connexion redirige l’utilisateur vers le cluster WFE du service Power BI le plus proche déterminé avec un code d’authentification.

  5. Le cluster WFE se connecte à Microsoft Entra ID pour obtenir un jeton de sécurité Microsoft Entra à l'aide du code d'authentification. Lorsque Microsoft Entra ID retourne l’authentification réussie de l’utilisateur et retourne un jeton de sécurité Microsoft Entra, le cluster WFE consulte le service global Power BI, qui gère une liste de locataires et leurs emplacements de cluster principal Power BI et détermine quel cluster de service principal Power BI contient le locataire de l’utilisateur. Le cluster WFE retourne ensuite une page d’application au navigateur de l’utilisateur avec la session, l’accès et les informations de routage requises pour son opération.

  6. À présent, lorsque le navigateur du client requiert des données client, il envoie des demandes à l’adresse du cluster principal avec le jeton d’accès Microsoft Entra dans l’en-tête d’autorisation. Le cluster principal Power BI lit le jeton d’accès Microsoft Entra et valide la signature pour vous assurer que l’identité de la demande est valide. Le jeton d’accès Microsoft Entra aura une date d’expiration définie conformément aux stratégies Microsoft Entra, et pour maintenir la session active, le client Power BI dans le navigateur de l’utilisateur effectue des demandes périodiques pour renouveler le jeton d’accès avant son expiration.

Diagramme montrant la séquence d’authentification WFE.

Ressources supplémentaires

Pour plus d’informations sur Power BI, consultez les ressources suivantes.

  • Last updated on