livre blanc sur la sécurité Power BI

résumé : Power BI est une offre de service logiciel en ligne (SaaS ou software as a service) de Microsoft qui vous permet de créer facilement et rapidement des tableaux de bord, des rapports, des jeux de données et des visualisations en libre-service. Avec Power BI, vous pouvez vous connecter à de nombreuses sources de données différentes, combiner et mettre en forme les données à partir de ces connexions, puis créer des rapports et des tableaux de bord partageables.

Enregistreurs : 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

Notes

Vous pouvez enregistrer ou imprimer ce livre blanc en sélectionnant Imprimer dans votre navigateur, puis en sélectionnant enregistrer en tant que PDF.

Introduction

Power BI est une offre de service logiciel en ligne (SaaS, ou Software as a Service) de Microsoft qui vous permet de créer facilement et rapidement des tableaux de bord, des rapports, des jeux de données et des visualisations de décisionnel en libre-service. Avec Power BI, vous pouvez vous connecter à de nombreuses sources de données différentes, combiner et mettre en forme les données à partir de ces connexions, puis créer des rapports et des tableaux de bord partageables.

Le monde évolue rapidement ; les organisations passent par une transformation numérique accélérée, et nous voyons une augmentation importante du travail à distance, une demande accrue des clients pour services en ligne et une utilisation accrue des technologies avancées en matière d’opérations et de prise de décision. Tout cela est alimenté par le Cloud.

Étant donné que la transition vers le Cloud est passée d’une percolation à une inondation, et avec la nouvelle surface exposée qui l’accompagne, de plus en plus d’entreprises demandent Comment sécuriser mes données dans le Cloud ? et quelle protection de bout en bout est disponible pour empêcher les fuites 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 dizaines d’années de bases du modèle de sécurité BI-niveau objet et sécurité au niveau des lignes, tout en étant très importants, ne suffisent plus à fournir le type de sécurité nécessaire dans l’ère du Cloud. Au lieu de cela, les organisations doivent rechercher une solution de sécurité de défense en profondeur Cloud native à plusieurs niveaux pour leurs données décisionnelles.

Power BI a été conçu pour fournir une protection complète et étanche du secteur des données. Le produit a obtenu les classifications de sécurité les plus élevées disponibles dans le secteur, et aujourd’hui beaucoup de sociétés de sécurité nationales, d’institutions financières et de fournisseurs de soins de santé le confient à leurs informations les plus sensibles.

Tout commence par la Fondation. Au terme de la période approximative des 2000 premières années, Microsoft a réalisé des investissements massifs pour résoudre ses vulnérabilités de sécurité, et au cours des décennies qui suivent, il a créé une pile de sécurité très puissante qui est aussi profonde que le noyau du BIOS machine sur puce et s’étend jusqu’à l’expérience des utilisateurs finaux. Ces investissements profonds se poursuivent, et aujourd’hui plus de 3 500 ingénieurs Microsoft s’engagent à créer et à améliorer la pile de sécurité de Microsoft et à répondre de manière proactive au paysage des menaces en perpétuelle évolution. Avec des milliards d’ordinateurs, des milliards de connexions et des zettabytess d’informations dignes de confiance à la protection de Microsoft, l’entreprise possède maintenant la pile de sécurité la plus avancée dans le secteur de la technologie et est largement affichée comme leader mondial de la lutte contre les acteurs malveillants.

Power BI s’appuie sur cette base très solide. Il utilise la même pile de sécurité que celle qui a permis à Azure de servir et de protéger les données les plus sensibles au monde, et il s’intègre aux outils de conformité et de protection des informations les plus avancés de Microsoft 365. En plus de celles-ci, elle offre une sécurité par le biais de mesures de sécurité multicouches, ce qui permet de bénéficier d’une protection de bout en bout conçue pour gérer les défis uniques de l’ère du Cloud.

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

  • Comment contrôler qui peut se connecter, à partir d’où ils se connectent et comment ils se connectent ? Comment 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 faire contrôler et protéger mes données sensibles ? Comment faire s’assurer que ces données ne peuvent pas entraîner de fuite en dehors de l’Organisation ?
  • Comment faire audit qui exécute quelles opérations ? Comment faire Réagissez 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 du service et explique comment les flux principaux du système fonctionnent. il explique ensuite comment 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 traite des 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 d’utilisation de Microsoft Online Services et la Déclaration de confidentialité de Microsoft Enterprise. Pour plus d’informations sur l’emplacement du traitement des données, reportez-vous à l’emplacement des termes du traitement des données dans les conditions de Microsoft Online Services et à l’Addendum sur la protection des données. Pour les informations sur la conformité, le Centre de gestion de la confidentialité Microsoft est la ressource principale pour Power BI. L’équipe Power BI travaille sans relâche pour proposer à ses clients les dernières innovations et une meilleure productivité. En savoir plus sur la conformité dans les offres de conformité Microsoft.

le service Power BI suit le cycle de vie de développement de la sécurité (SDL), des pratiques de sécurité strictes qui prennent en charge les exigences de conformité et de sécurité. 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 dans les logiciels, tout en réduisant les coûts de développement. En savoir plus sur les pratiques du cycle de vie de développement de sécurité Microsoft.

architecture Power BI

le service Power BI est basé sur Azure, la plateforme cloud computingde Microsoft. Power BI est actuellement déployé dans un grand nombre de centres de données du monde entier. De nombreux déploiements actifs sont mis à la disposition des clients dans les régions prises en charge par ces centres de données, tandis qu’un nombre égal de déploiements passifs font office de sauvegarde pour chaque déploiement actif.

Le WFE et le back-end

Cluster Web frontal (WFE)

le cluster WFE fournit au navigateur de l’utilisateur le contenu de la page HTML initiale sur le site load et gère le processus de connexion et d’authentification initial pour Power BI, en utilisant Azure Active Directory (Azure AD) pour authentifier les clients et fournir des jetons pour les connexions clientes ultérieures au service principal Power BI.

Le cluster WFE

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

Le cluster WFE affecté à l’utilisateur gère la séquence de connexion et d’authentification (décrite plus loin dans cet article) et obtient un jeton d’accès Azure AD une fois l’authentification réussie. le composant ASP.NET du cluster WFE analyse le jeton pour déterminer l’organisation à laquelle l’utilisateur appartient, puis consulte le Service Global Power BI. WFE spécifie au navigateur le cluster principal qui héberge le locataire de l’organisation. une fois qu’un utilisateur est authentifié, les interactions clientes ultérieures pour les données client se produisent avec le serveur principal ou Premium cluster directement, sans que le WFE soit un intermédiateur pour ces requêtes.

les ressources statiques telles que *.js, *. css et les fichiers image sont principalement stockées sur des réseau de distribution de contenu Azure (CDN) et récupérées directement par le navigateur. notez que les déploiements de clusters souverains sont une exception à cette règle et que, pour des raisons de conformité, vous devez omettre le CDN et utiliser à la place un cluster WFE à partir d’une région conforme pour héberger le contenu statique.

Power BI cluster principal (est)

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

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

Chaque cluster principal est avec état et héberge toutes les données de tous les locataires attribués à ce cluster. Un cluster qui contient les données d’un locataire spécifique est appelé le cluster d’hébergement du locataire. Les informations du cluster d’hébergement d’un utilisateur authentifié sont fournies par le service global et utilisées par le serveur Web frontal pour acheminer les demandes vers le cluster d’hébergement du locataire.

chaque cluster principal est constitué de plusieurs machines virtuelles combinées en plusieurs groupes redimensionnables à l’échelle ajusté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 et les données des locataires sont stockées dans des limites de cluster, à l’exception de la réplication de données vers un cluster principal secondaire dans une région Azure couplé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 moment.

Les fonctionnalités principales sont fournies par les micro-services exécutés sur des ordinateurs différents au sein du réseau virtuel du cluster et qui ne sont pas accessibles à partir de l’extérieur, à l’exception de deux composants accessibles depuis l’Internet public :

  • Service de passerelle
  • Gestion des API Azure

Le cluster principal

infrastructure Power BI Premium

Power BI Premium offre un service pour les abonnés qui ont besoin de fonctionnalités Premium Power BI, telles que flux, les rapports paginés, l’intelligence artificielle, etc. lorsqu’un client s’inscrit à un abonnement Power BI Premium, la capacité Premium est créée via le Azure Resource Manager.

les capacités de Power BI Premium sont hébergées dans des clusters principaux qui sont indépendants des Power BI standard back end, voir ci-dessus). cela offre une meilleure isolation, l’allocation des ressources, la prise en charge, l’isolation de la sécurité et l’é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, selon le scénario de l’utilisateur. les clients Power BI Premium peuvent être le navigateur d’un utilisateur, un Power BI standard back end, des connexions directes via des clients XMLA, des api ARM, etc.

l’infrastructure Power BI Premium dans une région Azure est constituée de plusieurs clusters Power BI Premium (le minimum est un). la majorité des ressources de Premium sont encapsulées à l’intérieur d’un cluster (par exemple, compute) et il existe des ressources régionales communes (par exemple, le stockage des métadonnées). Premium infrastructure offre deux moyens d’atteindre une évolutivité horizontale dans une région : l’augmentation des ressources dans les clusters et/ou l’ajout de clusters à la demande en fonction des besoins (si les ressources de cluster s’approchent de leurs limites).

La structure fondamentale de chaque cluster est celle des ressources de calcul gérées par Virtual Machine Scale sets (VMSS) et Azure Service Fabric. VMSS et Service Fabric permettent une augmentation rapide et sans peine des nœuds de calcul à mesure que l’utilisation augmente et orchestre le déploiement, la gestion et la surveillance des services et applications Power BI Premium.

De nombreuses ressources sont disponibles pour garantir une infrastructure sécurisée et fiable : équilibreurs de charge, réseaux virtuels, groupes de sécurité réseau, service bus, stockage, etc. les secrets, les clés et les certificats requis pour Power BI Premium sont gérés exclusivement par Azure Key Vault . Toute authentification s’effectue par le biais de l’intégration avec Azure AD exclusivement.

toute demande qui est envoyée à Power BI Premium infrastructure va 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 demande, la gèrent ou la transfèrent aux ressources appropriées (par exemple, les nœuds principaux).

les nœuds principaux fournissent la plupart des fonctionnalités et fonctionnalités de Power BI Premium.

Power BI Mobile

Power BI Mobile est un ensemble d’applications conçu pour les trois principales plateformes mobiles : Android, iOS et Windows (UWP). les considérations relatives à la sécurité pour les applications Power BI Mobile se répartissent en deux catégories :

  • Communication de l’appareil
  • L’application et les données sur l’appareil

pour la communication de l’appareil, toutes les applications Power BI Mobile communiquent avec le service Power BI et utilisent les mêmes séquences de connexion et d’authentification que celles 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 dans 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 montre la prise en charge de l’authentification basée sur les certificats (CBA) pour Power BI Mobile, en fonction de la plateforme d’appareil Mobile :

Support CBA iOS Android Windows
Power BI (connexion au service) Prise en charge Prise en charge Non pris en charge
AD FS SSRS local (se connecter au serveur SSRS) Non pris en charge Prise en charge Non pris en charge
Proxy d’application SSRS Prise en charge Prise en charge Non pris en charge

Les applications Power BI Mobile communiquent activement avec le service Power BI. La télémétrie est utilisée pour collecter des 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 des données sur l’appareil qui facilite l’utilisation de l’application :

  • Les Azure AD et les jetons d’actualisation sont stockés dans un mécanisme sécurisé sur l’appareil, à l’aide des mesures de sécurité standard du secteur.
  • 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 configurer ce paramètre dans les paramètres. Dans Windows, elle est effectuée à 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 (sandbox) et un stockage interne accessible uniquement à l’application. pour l’application Windows, les données sont accessibles uniquement par l’utilisateur (et l’administrateur système).
  • La géolocalisation est activée ou désactivée explicitement par l’utilisateur. Si cette option 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. S’il est activé, Android et iOS ne prennent pas en charge les exigences en matière de résidence des données géographiques pour les notifications.

le chiffrement des données peut être amélioré en appliquant un chiffrement au niveau du fichier via Microsoft Intune, un service logiciel qui fournit la gestion des appareils mobiles et des applications. les trois plateformes pour lesquelles Power BI Mobile est disponible prennent en charge Intune. Quand Intune est 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 les Microsoft Intune.

l’application Windows prend également en charge les Information Protection de Windows (WIP).

pour implémenter l’authentification unique, certaines valeurs de stockage sécurisées associées à l’authentification basée sur les jetons sont disponibles pour d’autres applications Microsoft de première partie (comme Microsoft Authenticator) et sont gérées par le kit de développement logiciel (SDK) de la bibliothèque d’authentification Azure Active Directory (ADAL).

Power BI Mobile données mises en cache 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 de mot de passe). Le cache de données inclut les tableaux de bord et les rapports précédemment sollicités à 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 l’id de visage, l’id tactile ou un code secret pour iOS, ainsi que les données biométriques (id d’empreinte digitale) pour Android. En savoir plus sur l’identification supplémentaire.

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, réponses et 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 workflow d’octroi de code d’authentification de l’Azure Active Directory. Pour plus d’informations sur les options des modèles d’authentification utilisateur d’une organisation (modèles de connexion), consultez choix d’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 établit une connexion au service Power BI à partir d’un navigateur, soit en tapant son adresse Power BI dans la barre d’adresses, soit en sélectionnant se connecter à partir de la page d’accueil de Power BI ( https://powerbi.microsoft.com) . La connexion est établie à l’aide de TLS 1.2 et HTTPS, et toutes les communications ultérieures entre le navigateur et le service Power BI utilisent le protocole HTTPS.

  2. le Azure Traffic Manager vérifie l’enregistrement dns de l’utilisateur pour déterminer le centre de centres le plus approprié (généralement le plus proche) dans lequel 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 que l’utilisateur a été authentifié, la page de connexion redirige l’utilisateur vers le cluster du service WFE Power BI le plus proche précédemment déterminé avec un code d’authentification.

  5. Le cluster WFE vérifie auprès du service Azure AD qu’il obtient un jeton de sécurité Azure AD à l’aide du code d’authentification. lorsque Azure AD retourne la réussite de l’authentification de l’utilisateur et retourne un jeton de sécurité Azure AD, le cluster WFE consulte le Service Global Power BI, qui gère une liste de locataires et leurs Power BI emplacements du cluster principal et détermine quel Power BI cluster de Service principal contient le locataire de l’utilisateur. Le cluster WFE retourne ensuite une page d’application au navigateur de l’utilisateur avec les informations de session, d’accès et de routage requises pour son fonctionnement.

  6. Désormais, lorsque le navigateur du client exige des données client, il envoie les demandes à l’adresse du cluster principal avec le jeton d’accès Azure AD dans l’en-tête Authorization. le cluster principal Power BI lit le jeton d’accès Azure AD et valide la signature pour s’assurer que l’identité de la demande est valide. Le jeton d’accès Azure ad a une durée de vie par défaut de 1 heure, et pour conserver la session active, le navigateur de l’utilisateur effectue des demandes périodiques pour renouveler le jeton d’accès avant qu’il n’expire.

Séquence d’authentification

Résidence des données

sauf indication contraire dans la documentation, Power BI stocke les données client dans une zone géographique Azure qui est affectée lorsqu’un locataire Azure AD s’inscrit pour Power BI services pour la première fois. Un locataire Azure AD 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’attribution d’une zone géographique azure pour le stockage des données du locataire s’effectue en mappant le pays ou la région sélectionné dans le cadre de la configuration du locataire Azure AD vers la géographie Azure la plus appropriée, où se trouve un déploiement Power BI. une fois cette détermination effectuée, tous les Power BI données client sont stockées dans cette région géographique Azure sélectionnée (également appelée zone géographique d’origine), sauf dans les cas où les organisations utilisent des déploiements multigéographiques.

Plusieurs zones géographiques (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 dans le États-Unis, mais elle peut également faire des affaires dans d’autres zones géographiques, telles que l’Australie. dans ce cas, l’entreprise peut exiger que certains Power BI données soient conservées au repos dans la région distante pour se conformer aux réglementations locales. cette fonctionnalité du service Power BI est appelée multi-géo.

La couche d’exécution de requête, les caches de requête et les données d’artefact affectés à un espace de travail à plusieurs zones géographiques sont hébergés et restent dans la zone géographique Azure de capacité à distance. Toutefois, certaines métadonnées d’artefact, telles que la structure de rapport, peuvent rester stockées au repos dans la zone géographique d’hébergement du locataire. en outre, le transit et le traitement des données peuvent toujours se produire dans la zone géographique de résidence du locataire, même pour les espaces de travail hébergés dans une capacité à plusieurs zones géographiques Premium.

pour plus d’informations sur la création et la gestion des déploiements Power BI qui s’étendent sur plusieurs zones géographiques Azure, consultez configurer la prise en charge de plusieurs zones géographiques pour les Power BI Premium .

Régions et centres de.

les services de 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, consultez le centre de gestion de la confidentialité Microsoft. Les engagements concernant l’emplacement des données client au repos sont spécifiés dans les conditions de traitement des données des conditions de Microsoft Online Services.

Microsoft fournit également des centres de connaissances pour les entités souveraines. Pour plus d’informations sur la disponibilité du service Power BI pour les clouds nationaux, consultez Clouds nationaux Power BI.

Gestion des données

cette section décrit Power BI pratiques de gestion des données lorsqu’il s’agit de stocker, traiter et 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 SQL Azure

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

toutes les données conservées 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 Transparent Data Encryption (TDE) d’azure SQL . les données client stockées dans le stockage d’objets 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 afin de chiffrer les données au repos qui sont importées dans un jeu de données. Cette approche est souvent décrite par le terme Bring Your Own Key (BYOK). L’utilisation de BYOK permet de garantir que même en cas d’erreur d’opérateur de service, les données client ne sont pas exposées, ce qui n’est pas facile à réaliser à l’aide d’un chiffrement transparent côté service. pour plus d’informations, consultez apporter vos propres clés de chiffrement pour Power BI .

les jeux de données Power BI autorisent divers modes de connexion à la source de données qui déterminent si les données de la source de données sont conservées ou non dans le service.

Mode jeu de données (Kind) Données conservées dans Power BI
Importer Oui
Direct Query Non
Live Connect Non
Composite Si contient une source de données d’importation
Diffusion en continu Si configuré pour persister

quel que soit le mode de jeu de données utilisé, Power BI peut mettre temporairement en cache les données extraites pour optimiser les performances de requête et de chargement des rapports.

Données en cours de traitement

Les données sont en cours de traitement 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 des données traitées activement dans l’espace mémoire d’une ou plusieurs charges de travail de service. Pour faciliter la fonctionnalité requise par la charge de travail, les données traitées dans la mémoire ne sont pas chiffrées.

Données en transit

Power BI nécessite le chiffrement de tout le trafic HTTP entrant à l’aide de TLS 1,2 ou version ultérieure. Toutes les demandes tentant d’utiliser le service avec TLS 1,1 ou une valeur antérieure seront rejetées.

Authentification auprès des 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 que le jeu de données est 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 jeu de données sont utilisées pour la connexion à la source de données.

Si une source de données est connectée directement à l’aide des 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 consulte 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 consulte les données. En cas d’utilisation avec l’authentification unique, 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 auxquelles ils ont des privilèges d’accès. Lorsque la connexion concerne des sources de données dans le Cloud, Azure AD authentification est utilisée pour l’authentification unique ; pour les sources de données local, Kerberos, Security Assertion Markup Language (SAML) et Azure AD sont pris en charge.

si la source de données est Azure Analysis Services ou Analysis Services locale, et que la sécurité au niveau des lignes et/ou OLS est configurée, le service de Power BI applique cette sécurité au niveau de la ligne, et les utilisateurs qui ne disposent pas d’informations d’identification suffisantes 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

fonctionnalités de Premium

Architecture flux

Les flux offrent aux utilisateurs la possibilité de configurer des opérations de traitement de données principales qui extraient des données de sources de données polymorphes, exécutent la logique de transformation sur les données, puis les transportent dans un modèle cible pour une utilisation sur diverses technologies de présentation de création de rapports. Tout utilisateur disposant d’un rôle de membre, de contributeur ou d’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 ils ne peuvent 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 s’appropriant le flux de travail.

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 Power Query services pendant que les données sont en cours de vol. Pour les flux Premium, les services Power Query s’exécutent dans des nœuds principaux. Les données peuvent être extraites directement à partir des sources Cloud ou via une passerelle installée localement. Lorsqu’elles sont extraites directement d’une source Cloud vers le service ou vers la passerelle, le transport utilise une méthodologie de protection spécifique à la technologie client, 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 traitement des données ci-dessus.

Lorsque les sources de données spécifiées par le client requièrent 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 standard des informations d’identification à l’ensemble du produit. Consultez la section authentification auprès des sources de données ci-dessus. Il existe plusieurs 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 Power BI propriétaire et un compte de stockage protégé. Stockage le chiffrement est activé sur les conteneurs de stockage d’objets Blob pour protéger les données pendant qu’elles sont au repos. Consultez la section données dans Rest 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 de pouvoir 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 de stockage ADLS configuré. Les données sont toujours transmises au stockage d’objets BLOB à l’aide du chiffrement.

étant donné que les performances lors de l’accès aux comptes de stockage peuvent être non optimales pour certaines données, les utilisateurs ont également la possibilité d’utiliser un moteur de calcul hébergé par Power BI pour améliorer 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 de 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 chiffrer le doublon.

Lors de l’interrogation à l’aide de DirectQuery, le protocole de transport chiffré HTTPs est utilisé pour accéder à l’API. Toutes les utilisations secondaires ou indirectes de DirectQuery sont contrôlées par les mêmes contrôles d’accès que ceux décrits précédemment. Étant donné que les flux 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 disposer au moins de l’accès en lecture pour pouvoir interroger les données par le biais de n’importe quel moyen.

lorsque Power BI Desktop est utilisé pour accéder aux données d’un flux de données, il doit d’abord authentifier l’utilisateur à l’aide de Azure AD pour déterminer si l’utilisateur dispose des droits suffisants pour afficher les données. Si c’est le cas, une clé SaS est acquise et utilisée pour accéder directement au stockage à l’aide du protocole de transport chiffré HTTPs.

le traitement des données dans le pipeline émet Office 365 événements d’audit. 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, car ils sont mis en forme pour tenir sur une page. Ils affichent toutes les données dans une table, même si la table s’étend sur plusieurs pages. Ils sont appelés « pixel parfait », car vous pouvez contrôler exactement leur mise en page.

les rapports paginés prennent en charge les expressions riches et puissantes écrites dans Microsoft Visual Basic .net. Les expressions sont largement utilisées dans les rapports paginés Power BI Report Builder pour récupérer, calculer, afficher, regrouper, trier, filtrer, paramétrer et mettre en forme les données.

Les expressions sont créées par l’auteur du rapport avec un 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 (sandbox).

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 la section authentification auprès du Service Power BI ci-dessus.

le jeton Azure AD obtenu pendant l’authentification est utilisé pour communiquer directement à partir du navigateur au cluster Power BI Premium.

pour Premium Gen1, un seul bac à sable (sandbox) existe pour chacune des capacités du locataire et est partagé par les espaces de travail affectés à la capacité.

Rapports paginés, génération 1

pour Premium gen (en préversion), un bac à sable (sandbox) individuel et exclusif est créé pour chaque rendu d’un rapport, ce qui fournit un niveau d’isolement plus élevé entre les utilisateurs.

Rapports paginés, génération 2

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

afin de prendre en charge des fonctionnalités telles que les Bing maps ou les appels à Azure Functions, le bac à sable (sandbox) a accès à internet.

Power BI Embedded Analytics

les éditeurs de logiciels indépendants (isv) et les fournisseurs de solutions ont deux modes principaux d’incorporation de Power BI artefacts 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 ou du portail web externe, et la communication avec l’iframe s’effectue à l’aide du kit de développement logiciel (SDK) Client Power BI à l’aide de messages de publication.

dans un scénario d' incorporation pour votre organisation , Azure AD utilisateurs accèdent à leur propre Power BI de contenu via des portails personnalisés par leurs entreprises et leurs. toutes les stratégies et fonctionnalités de Power BI décrites dans ce document, telles que Sécurité au niveau des lignes (RLS) et la sécurité au niveau de l’objet (OLS), sont automatiquement appliquées à tous les utilisateurs, indépendamment du fait qu’ils accèdent Power BI via le portail Power BI ou via des portails personnalisés.

dans un scénario d' incorporation pour votre client , les éditeurs de logiciels indépendants possèdent généralement Power BI locataires et Power BI artefacts (tableaux de bord, rapports, jeux de données, etc.). Il incombe à un service principal ISV d’authentifier ses utilisateurs finaux et de décider quels artefacts et quel niveau d’accès convient pour cet utilisateur final. les décisions de stratégie ISV sont chiffrées dans un jeton incorporé généré par Power BI et transmises au serveur principal isv pour une distribution supplémentaire aux utilisateurs finaux en fonction de la logique métier de l’isv. Les utilisateurs finaux qui utilisent un navigateur ou d’autres applications clientes ne sont pas en mesure de déchiffrer ou de modifier les jetons d’incorporation. les kits de développement logiciel (sdk) côté client, tels que Power BI les api clientes , ajoutent automatiquement le jeton d’incorporation chiffré aux demandes Power BIen tant qu’en-tête authorization : incorporation . sur la base de cet en-tête, Power BI appliquera toutes les stratégies (telles que l’accès ou la sécurité au niveau des lignes) exactement comme spécifié par l’ISV lors de la génération.

pour activer l’incorporation et l’automatisation, et pour générer les jetons d’incorporation 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 de l’utilisateur délégué et du principal de service Azure AD.

Power BI analytique incorporée et ses api REST prennent en charge toutes les fonctionnalités d’isolement réseau Power BI décrites dans cet article : par exemple, les balises de Service et les liens privés.

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 éléments visuels ai et les enrichissements ai. Les fonctionnalités de l’IA de niveau visuel incluent des fonctionnalités telles que les influenceurs clés, la décomposition d’arborescence, la narration intelligente, la détection d’anomalie, R-Visual, Python-Visual, le clustering, les prévisions, Q&A, Quick-Insights etc. Les fonctionnalités d’enrichissement d’AI incluent des fonctionnalités telles que les transformations AutoML, AzureML, Cognitiveservices Account, 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 dès aujourd’hui. toutefois, AutoML et cognitiveservices account sont pris en charge uniquement dans les espaces de travail Premium, en raison de restrictions d’adresse IP. aujourd’hui, avec l’intégration de AutoML dans Power BI, un utilisateur peut créer et effectuer l’apprentissage d’un modèle de ML personnalisé (par exemple, prédiction, Classification, régression, etc.) et l’appliquer pour obtenir des prédictions lors du chargement des données dans un flux de données défini dans un espace de travail Premium. en outre, Power BI utilisateurs peuvent appliquer plusieurs api cognitiveservices account, telles que TextAnalytics et ImageTagging, pour transformer des données avant de les charger dans un flux de données/jeu de données défini dans un espace de travail Premium.

les fonctionnalités d’enrichissement Premium ai peuvent être mieux consultées sous la forme d’une collection de fonctions et de transformations ai sans état qui peuvent être utilisées par Power BI utilisateurs dans leurs pipelines d’intégration de données utilisés par un jeu de données ou un flux de données Power BI. notez que ces fonctions sont également accessibles à partir des environnements de création de flux de données/jeux de données actuels dans le Service Power BI et Power BI Desktop. ces fonctions et transformations AI s’exécutent toujours dans une Premium espace de travail/capacité. ces fonctions sont exposées dans Power BIen tant que source de données qui requiert un jeton Azure AD pour le Power BI utilisateur qui utilise la fonction ia. Ces sources de données AI sont spéciales, car elles ne surfacent aucune de leurs propres données et ne fournissent que ces fonctions/transformations. Pendant l’exécution, ces fonctionnalités n’effectuent pas d’appels sortants vers d’autres services pour transmettre les données du client. examinons les scénarios de Premium pour comprendre les modèles de communication et les détails relatifs à la sécurité qui s’y rapportent.

pour la formation 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. lors des itérations d’apprentissage, Power BI appelle un service AzureML expérimentation pour sélectionner un modèle et des hyperparamètres appropriés pour l’itération actuelle. Dans cet appel sortant, seules les métadonnées d’expérimentation pertinentes (par exemple, la précision, l’algorithme ml, les paramètres d’algorithme, etc.) de l’itération précédente sont envoyées. La formation AutoML produit un modèle ONNX et des données de rapport d’apprentissage qui sont ensuite enregistrées dans le flux de données. plus tard, Power BI utilisateurs peuvent ensuite appliquer le modèle de ML formé en tant que transformation pour mettre en œuvre le modèle de ML sur une base planifiée. pour les api TextAnalytics et ImageTagging, Power BI n’appelle pas directement les api de service cognitiveservices account, mais utilise plutôt un kit de développement logiciel (SDK) interne pour exécuter les api dans la capacité Power BI Premium. aujourd’hui, ces api sont prises en charge dans les Power BI flux et les jeux de données. lors de la création d’un jeu de données dans Power BI Desktop, les utilisateurs peuvent accéder à cette fonctionnalité uniquement s’ils ont accès à un Premium Power BI espace de travail. Par conséquent, les clients sont invités à fournir leurs informations d’identification de Azure AD.

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 licences. Pour plus d’informations, consultez les sections ci-dessous.

Balises de service

Une balise de service représente un groupe de préfixes d’adresses IP d’un service Azure donné. Cela permet de réduire la complexité des mises à jour fréquentes des règles de sécurité réseau. Les clients peuvent utiliser les balises de service pour définir les contrôles d’accès réseau sur les groupes de sécurité réseau ou le 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 balise de service (par exemple, PowerBI) dans le champ source ou de destination (pour les API) approprié d’une règle, les clients peuvent autoriser ou refuser le trafic pour le service correspondant. Microsoft gère les préfixes d’adresse englobés par la balise de service et met à jour automatiquement la balise de service quand les adresses changent.

Les réseaux Azure offrent la fonctionnalité Azure Private Link qui permet à Power BI de garantir un accès sécurisé par le biais de points de terminaison privés Azure Networking. Avec les points de terminaison privés et de liaison privée Azure, le trafic de données est envoyé en privé à l’aide de l’infrastructure réseau principale de Microsoft, ce qui signifie que les données ne transitent pas par Internet.

le lien privé garantit que les utilisateurs de Power BI utilisent le segment principal du réseau privé Microsoft pour accéder aux ressources du service Power BI.

l’utilisation d’un lien privé avec Power BI offre les avantages suivants :

  • Le lien privé garantit que le trafic transite par 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 disposent de ExpressRoute ou d’un réseau privé virtuel (VPN) configuré.

pour plus d’informations, consultez liens privés pour accéder à Power BI .

Connectivité au réseau virtuel (version préliminaire bientôt disponible)

tandis que la fonctionnalité d’intégration des liens privés fournit des connexions entrantes sécurisées à Power BI, la fonctionnalité de connectivité de réseau virtuel permet une connectivité sortante sécurisée à partir de Power BI vers les 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 aux sources de données associées à un réseau virtuel. Toutefois, ils suivent toujours le processus familier de gestion des sources de données et de sécurité, comme dans le cas d’une passerelle de données locale.

voici une vue d’ensemble de ce qui se passe lorsque vous interagissez avec un rapport de 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 reçoit 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 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 vers le service cloud Power BI.

Ce composant sera bientôt disponible en version préliminaire publique.

Principaux de service

Power BI prend en charge l’utilisation de principaux de service. stockez les informations d’identification du principal de service utilisées pour le chiffrement ou l’accès à Power BI dans un Key Vault, assignez des stratégies d’accès appropriées au coffre et examinez régulièrement les autorisations d’accès.

pour plus d’informations, consultez automatiser Premium tâches relatives à l’espace de travail et au jeu de données avec les principaux du service .

Protection contre la perte de données (DLP)

Microsoft 365 les étiquettes de sensibilité

Power BI a une intégration profonde avec des étiquettes de sensibilité de Protection des données Microsoft (MIP), qui permettent aux organisations de disposer d’une solution unique et intégrée pour la gestion des stratégies DLP, l’audit et la conformité dans la suite de Office.

Lorsque les étiquettes de sensibilité sont activées dans Power BI :

  • les données sensibles, à la fois dans le service de Power BI (GA) et dans Power BI Desktop (version préliminaire), peuvent être classées et étiquetées à l’aide des mêmes étiquettes de sensibilité de Protection des données Microsoft familières que celles utilisées dans Office et dans Azure portée.
  • les stratégies de gouvernance peuvent être appliquées, même si le contenu Power BI est exporté vers des fichiers Excel, PowerPoint, PDF ou . pbix , afin de garantir la protection des données même quand elles quittent Power BI.
  • les fichiers . pbix peuvent être chiffrés selon les stratégies de l’étiquette MIP lorsqu’une étiquette MIP est appliquée au fichier . Pbix sur le bureau, garantissant ainsi que seuls les utilisateurs autorisés peuvent modifier ce fichier.
  • il est facile de classer et de protéger les fichiers . pbix comme il le fait avec les fichiers Excel, Word et PowerPoint. En deux clics, un fichier peut être balisé en fonction de son niveau de sensibilité et, encore plus, être chiffré s’il contient des données confidentielles de l’entreprise.
  • Excel classeurs héritent automatiquement des étiquettes de sensibilité lorsqu’ils se connectent à Power BI (version préliminaire), ce qui permet de maintenir la classification de bout en bout et d’appliquer la protection lorsque le jeu de données Power BI est analysé dans Excel.
  • les étiquettes de sensibilité appliquées sur Power BI rapports et les tableaux de bord seront visibles dans les applications mobiles Power BI iOS et Android.
  • les étiquettes de sensibilité persistent lorsqu’un rapport de Power BI est incorporé dans Teams, SharePoint ou un site web sécurisé (version préliminaire). 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 d’un nouveau contenu dans le service Power BI garantit que l’étiquette appliquée sur un jeu de données dans le service Power BI sera appliquée sur le nouveau contenu créé sur le jeu de données.
  • Power BI les api d’analyse d’administration peuvent extraire l’étiquette de sensibilité d’un artefact Power BI, ce qui permet aux Power BI et aux administrateurs InfoSec de surveiller l’étiquetage dans le service Power BI et de produire des rapports d’encadrement.
  • Power BI permet de s’assurer que seuls les utilisateurs autorisés peuvent modifier ou supprimer des étiquettes avec des paramètres de protection dans le service Power BI.
  • Bientôt disponible
    • Power BI les api d’administration pour l’application des étiquettes MIP pour permettre aux équipes centrales d’étiqueter par programme le contenu du service Power BI.
    • les administrateurs peuvent appliquer l’application d’étiquettes sur du contenu nouveau ou modifié avec une stratégie d’étiquette obligatoire dans le service Power BI (version préliminaire).
    • étiquetage automatique des artefacts en aval au sein du service Power BI. Lorsqu’une étiquette d’un jeu de données est appliquée ou modifiée, l’étiquette est automatiquement appliquée à tout le contenu en aval connecté à cet artefact.

pour plus d’informations, consultez la documentation sur l’étiquette de sensibilité Protection des données Microsoft dans Power BI .

Microsoft Cloud App Security (MCAS) pour Power BI

Microsoft Cloud App Security est l’un des principaux courtiers en matière de sécurité d’accès au cloud, intitulé « leader » dans le Magic Quadrant de Gartner pour le marché du service Broker pour la sécurité des accès cloud (CASB). Cloud App Security est utilisé pour sécuriser l’utilisation des applications Cloud. elle permet aux organisations de surveiller et de contrôler, en temps réel, les Power BI les sessions telles que l’accès des utilisateurs à partir d’appareils non gérés. Les administrateurs de la 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 Sécurité des applications cloud, les organisations peuvent bénéficier des fonctionnalités DLP suivantes :

  • Définir des contrôles en temps réel pour appliquer des sessions utilisateur à risque dans Power BI. par exemple, si un utilisateur se connecte à Power BIen dehors de son pays, la session peut être surveillée par les contrôles en temps réel de Sécurité des applications cloud, et les actions risquées, telles que le téléchargement de données marquées avec une étiquette de sensibilité « hautement confidentiel », peuvent être bloquées immédiatement.
  • examinez Power BI activité de l’utilisateur avec le journal d’activité de Sécurité des applications cloud. le journal d’activité Sécurité des applications cloud inclut Power BI activité capturée dans le journal d’audit Office 365, qui contient des informations sur toutes les activités d’utilisateur et d’administration, ainsi que des informations d’étiquette de sensibilité pour les activités pertinentes, telles que l’application, la modification et la suppression d’une étiquette. les administrateurs peuvent tirer parti des filtres avancés de Sécurité des applications cloud et des actions rapides pour une investigation efficace des problèmes.
  • Créer des stratégies personnalisées pour signaler une activité utilisateur suspecte dans Power BI. la fonctionnalité de stratégie d’activité de Sécurité des applications cloud peut être utilisée pour définir vos propres règles personnalisées, afin de vous aider à détecter le comportement de l’utilisateur qui s’écarte de la norme et peut même agir automatiquement, s’il semble trop dangereux.
  • travaillez avec la détection d’anomalie intégrée de Sécurité des applications cloud. les stratégies de détection des anomalies d’Sécurité des applications cloud fournissent des analyses et des Machine Learning de comportement utilisateur prêts à l’emploi, afin que vous soyez prêt dès le départ pour exécuter une détection avancée des menaces dans votre environnement cloud. Lorsqu’une stratégie de détection d’anomalies identifie un comportement suspect, elle déclenche une alerte de sécurité.
  • Power BI rôle d’administrateur dans le portail Sécurité des applications cloud. Sécurité des applications cloud 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 de Power BI pertinentes dans le portail, telles que les alertes, les utilisateurs à risque, les journaux d’activité et d’autres informations relatives au Power BI.

pour plus d’informations, consultez utilisation des contrôles de Microsoft Cloud App Security dans Power BI .

Aperçu des fonctionnalités de sécurité

Cette rubrique répertorie les fonctionnalités dont la publication est prévue jusqu’au 2021 mars. Étant donné que cette rubrique répertorie les fonctionnalités qui n’ont peut-être pas encore été publiées, les chronologies de remise peuvent changer et les fonctionnalités projetées peuvent être publiées plus tard que le 2021 mars, ou ne pas être publiées. Pour plus d’informations sur les préversions, consultez les conditions des services en ligne.

Apportez vos propres Log Analytics (BYOLA)

apportez votre propre Log Analytics permet l’intégration entre Power BI et Azure Log Analytics. Cette intégration comprend le moteur d’analyse avancé, le langage de requête interactif et les constructions de Machine Learning intégrées à Azure Log Analytics.

Power BI questions et réponses de sécurité

Voici quelques questions et réponses courantes relatives à la sécurité dans Power BI. Ils sont organisés en fonction de la date à laquelle ils ont été ajoutés à ce livre blanc, afin de vous permettre de 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 et accèdent aux sources de données quand ils utilisent Power BI ?

  • Power BI gère les informations d’identification pour les sources de données de 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 au sein de l’entreprise et les autorisations sur ces sources de données peuvent être gérées par l’administrateur de la passerelle. Lors de la configuration d’un jeu de données, l’utilisateur est autorisé à sélectionner des informations d’identification dans 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 jeu de données publié dans Power BI service, 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 le tableau de bord n’accèdent 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 jeu de données sont utilisées pour la connexion à la source de données.

    Pour les rapports qui sont 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 la connexion à la source de données lorsqu’un utilisateur consulte 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 consulte les données. Lorsque vous utilisez avec l’authentification unique, 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, ce qui permet aux utilisateurs d’afficher les données auxquelles ils ont des privilèges d’accès. Lorsque la connexion concerne des sources de données dans le Cloud, Azure AD authentification est utilisée pour l’authentification unique ; pour les sources de données local, Kerberos, SAML et Azure AD sont pris en charge.

    Lors de la connexion avec Kerberos, l’UPN de l’utilisateur est transmis à la passerelle et l’utilisation de la délégation Kerberos restreinte permet à l’utilisateur d’emprunter l’identité et de se connecter aux sources de données respectives. SAML est également pris en charge sur la passerelle pour SAP HANA DataSource. Des informations supplémentaires sont disponibles dans vue d’ensemble de l’authentification unique pour les passerelles.

    si la source de données est Azure Analysis Services, Analysis Services et Sécurité au niveau des lignes (RLS) et/ou la sécurité au niveau de l’objet (OLS) est configurée, le service Power BI applique la sécurité au niveau des lignes, et les utilisateurs qui ne disposent pas d’informations d’identification suffisantes 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.

    la sécurité au niveau des lignes avec Power BI peut être utilisée pour restreindre l’accès aux données pour les utilisateurs donnés. Les filtres restreignent l’accès aux données au niveau de la ligne et vous pouvez définir des filtres dans Role.

    La sécurité au niveau de l’objet (OLS) peut être utilisée pour sécuriser des tables ou des colonnes sensibles. Toutefois, contrairement à la sécurité au niveau des lignes, la sécurité au niveau de l’objet sécurise également les noms d’objets et les métadonnées. Cela permet d’éviter que des utilisateurs malveillants découvrent même l’existence de ces objets. les tables et les colonnes sécurisées sont masquées dans la liste de champs lors de l’utilisation d’outils de création de rapports tels que 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 autorisation d’accès appropriée, les tables et les colonnes sécurisées n’existent pas.

    La sécurité au niveau de l’objet, ainsi que la sécurité au niveau des lignes, permettent une sécurité améliorée de l’entreprise sur les rapports et les jeux de données, garantissant que seuls les utilisateurs disposant des autorisations nécessaires ont accès à l’affichage et à l’interaction avec les données sensibles.

Comment les données sont transférées à 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 de la source de données au service de Power BI. Une connexion sécurisée est établie avec le fournisseur de données, et les données transitent par le réseau uniquement une fois que cette connexion est établie.

Comment Power BI met en cache les données des rapports, tableaux de bord ou modèles ? Cette mise en cache est-elle sécurisée ?

Les clients mettent-ils en cache localement les données des pages web ?

  • Quand les navigateurs clients accèdent à Power BI, les serveurs web Power BI affectent la valeur no-store à la directive Cache-Control. La directive no-store indique aux navigateurs qu’ils ne doivent pas mettre en cache la page web affichée par l’utilisateur et qu’ils ne doivent pas la stocker dans le dossier de cache du client.

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

  • Pour les sources de données pour lesquelles la sécurité au niveau du rôle n’est pas activée, si un tableau de bord, un rapport ou un modèle de données est partagé avec d’autres utilisateurs par le biais de Power BI, les données sont alors accessibles aux utilisateurs avec lesquels l’affichage et l’interaction sont partagés. Power BI ne ré-authentifie pas les utilisateurs auprès de la source d’origine des données. Une fois les données chargées dans Power BI, l’utilisateur qui s’est authentifié auprès des données sources est responsable de la gestion des autres utilisateurs et groupes pouvant visualiser les données.

    Lorsque des connexions de données sont effectuées sur une source de données basée sur RLS, par exemple une source de données Analysis Services, seules les données du tableau de bord sont mises en cache dans Power bi. Chaque fois qu’un rapport ou un jeu de données affiché ou sollicité dans Power BI utilise des données de la source de données prenant en charge la sécurité au niveau du rôle, le service Power BI accède à la source de données pour obtenir des données en fonction des informations d’identification de l’utilisateur, et si les autorisations sont suffisantes, les données sont chargées dans le rapport ou le modèle de données pour cet utilisateur. Si l’authentification échoue, l’utilisateur reçoit une erreur.

    Pour plus d’informations, consultez la section authentification auprès des sources de données plus haut dans ce document.

Nos utilisateurs se connectent à la même source de données tout le temps, dont certains requièrent des informations d’identification qui diffèrent de leurs informations d’identification de domaine. Comment peut-il éviter d’avoir à entrer ces informations d’identification chaque fois qu’elles effectuent une connexion de données ?

  • Power BI propose Power BI Personal Gateway, une fonctionnalité qui permet aux utilisateurs de créer des informations d’identification pour plusieurs sources de données différentes, puis d’utiliser automatiquement ces informations d’identification quand ils accèdent par la suite à chacune de ces sources de données. Pour plus d’informations, consultez Power BI Personal Gateway.

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

  • La réponse détaillée à cette question est disponible sur le lien suivant : ports de passerelle

Quand vous utilisez 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’est-ce que la gestion sécurisée des informations d’identification ?

  • Pendant l’installation et la configuration de la passerelle, l’administrateur entre une clé de récupération de 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 se trouvant sur l’ordinateur local. Ce fichier est également chiffré. Le contenu du fichier peut être déchiffré uniquement par cet ordinateur Windows spécifique, et uniquement par ce compte de service de passerelle spécifique.

    Quand 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 sont les protocoles de communication 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 requiert l’ouverture des ports 443, 5671-5672 et 9350-9354 pour la communication sortante. Il est recommandé, car il a une surcharge de communication plus faible.

    • HTTPs-WebSockets sur HTTPs + TLS : ce protocole utilise uniquement le port 443. Le WebSocket est lancé par un message HTTP CONNECT unique. 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 passerelle locale.

Quel est le rôle du CDN Azure dans Power BI ?

  • Comme mentionné plus haut, Power BI utilise Azure Content Delivery Network (CDN) pour distribuer efficacement les fichiers et le contenu statiques nécessaires aux utilisateurs en fonction des paramètres régionaux. Pour être plus précis, le service Power BI utilise plusieurs CDN pour distribuer efficacement les fichiers et le contenu statiques nécessaires aux utilisateurs par le biais de l’Internet public. Ces fichiers statiques contiennent des téléchargements de produits (tels que Power BI Desktop, la passerelle de données locale ou des applications Power BI de différents fournisseurs de services indépendants), des fichiers de configuration de navigateur servant à établir les connexions ultérieures avec le service Power BI, ainsi que la page initiale de connexion sécurisée à Power BI.

    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) afin de télécharger la collection des fichiers communs spécifiés nécessaires pour permettre l’interaction du navigateur avec le service Power BI. la page du navigateur comprend ensuite le jeton Azure AD, les informations de session, l’emplacement du cluster principal associé et la collection de fichiers téléchargés à partir du cluster Azure CDN et WFE, pour la durée de la session du navigateur de service Power BI.

pour Power BI visuels, 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 d’examiner le code de visuel personnalisé et de déterminer s’il est fiable. Tout le code des visuels personnalisés est exploité dans un environnement de bac à sable, afin que tout code errant dans un visuel personnalisé n’affecte pas le reste du service Power BI.

Y a-t-il d’autres visuels Power BI qui envoient des informations à l’extérieur du réseau client ?

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

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

  • Non. L’éditeur de l’application est responsable du contenu, alors qu’il est responsable du client de l’examiner et de déterminer s’il faut approuver l’éditeur de l’application de modèle.

Existe-t-il des applications de modèle qui peuvent envoyer des informations à l’extérieur 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 de modèle sur le locataire. Le serveur de publication 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 s’assurer que les données ne sont pas laissées dans les limites du pays ?

  • Certains clients dans certaines zones géographiques ont une option pour créer un locataire dans un cloud national, où le stockage et le traitement des données sont maintenus distincts de tous les autres centres de données. Les clouds nationaux ont un type de sécurité légèrement différent, car un tiers de confiance distinct pour les données exploite le service Power BI de cloud national pour le compte de Microsoft.

    Les clients peuvent également configurer un locataire dans une région spécifique. Toutefois, ces locataires n’ont pas d’administrateur de données distinct de Microsoft. Les tarifs des clouds nationaux sont différents du service Power BI commercial en disponibilité générale. Pour plus d’informations sur la disponibilité du service Power BI pour les clouds nationaux, consultez Clouds nationaux Power BI.

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

  • les connexions établies pour les clients avec des abonnements Power BI Premium implémentent un processus d’autorisation b2b (business-to-business) Azure , en utilisant Azure AD pour activer le contrôle d’accès et l’autorisation. Power BI gère les connexions à partir des abonnés Power BI Premium aux ressources Power BI Premium exactement comme il le ferait pour tout autre utilisateur Azure AD.

Commentaires et suggestions

Nous apprécions vos commentaires. Nous sommes intéressés par les suggestions d’amélioration, les ajouts ou les clarifications apportées à ce livre blanc, ou tout autre contenu relatif à Power BI. Envoyez vos suggestions à pbiss@microsoft.com .

Ressources supplémentaires

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