Livre blanc Sécurité dans 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.

É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, Yarivmon, 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 à partir de 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 change 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 services en ligne et une utilisation accrue des technologies avancées dans les opérations et la prise de décisions commerciales. Et tout cela est alimenté par le cloud.

Lorsque la transition vers le cloud a changé d’un filet à une inondation, et avec la nouvelle surface exposée qui lui est fournie, de plus en plus d’entreprises demandent comment mes données sont-elles sécurisées dans le cloud ? et Quelle est la protection de bout en bout disponible pour empêcher mes données sensibles de fuiter ? Et pour les plateformes bi qui gèrent souvent certaines des informations les plus stratégiques dans l’entreprise, ces questions sont doublement importantes.

Les décennies de base du modèle de sécurité BI - sécurité au niveau de l’objet et de la sécurité au niveau des lignes - tout en restant importantes, ne suffit plus clairement pour 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é multiniveau native et multiniveau native et multiniveau pour leurs données décisionnels.

Power BI a été conçu pour fournir une protection complète et hermetique complète et hermetique pour les données. Le produit a gagné les classifications de sécurité les plus élevées disponibles dans l’industrie, et aujourd’hui de nombreuses agences de sécurité nationale, 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, dans les décennies suivantes, a construit une pile de sécurité très forte qui va aussi loin que le noyau bios à puce de l’ordinateur et étend toutes les 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’attaquent de manière proactive au paysage des menaces qui changent toujours. Avec des milliards d’ordinateurs, des milliards 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 vue comme le leader mondial de la lutte contre les acteurs malveillants.

Power BI s’appuie sur cette base très forte. Il utilise la même pile de sécurité qui a gagné le droit de servir et de protéger les données les plus sensibles du monde, et il s’intègre aux outils de protection et de conformité les plus avancés de Microsoft 365. En plus de cela, il offre une 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 contrôler les connexions ?
  • Comment les données sont-elles stockées ?Comment est-il chiffré ?Quels contrôles dois-je avoir sur mes données ?
  • Comment faire contrôler et protéger mes données sensibles ?Comment faire vous assurer que ces données ne peuvent pas fuiter en dehors de l’organisation ?
  • Comment faire audit qui effectue les opérations ?Comment faire 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 les flux principaux du système fonctionnent. Il se déplace ensuite pour décrire 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 par le biais du 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 d’utilisation de Microsoft Online Services et la Déclaration de confidentialité de Microsoft Enterprise. Pour connaître l’emplacement du traitement des données, reportez-vous aux termes du traitement des données dans les conditions des services en ligne Microsoft et à l’addenda 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 du développement de la sécurité (SDL), des pratiques de sécurité strictes qui prennent en charge les exigences en matière 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 dans les logiciels, tout en réduisant les coûts de développement. En savoir plus sur les pratiques de cycle de vie du développement de sécurité Microsoft.

Architecture Power BI

Le service Power BI est basé sur azure, la plateforme cloud computing de 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 frontal web (WFE)

Le cluster WFE fournit le navigateur de l’utilisateur avec le contenu initial de la page HTML sur le chargement de site et gère le processus de connexion et d’authentification initial pour Power BI, à l’aide d’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 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 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 au sein du cluster WFE analyse le jeton pour déterminer l’organisation à laquelle appartient l’utilisateur, puis consulte le service global Power BI. Le WFE spécifie au navigateur auquel le cluster principal héberge le locataire de l’organisation. Une fois qu’un utilisateur est authentifié, les interactions client suivantes pour les données client se produisent avec le cluster back-end ou Premium directement, sans que le WFE soit un intermédiaire pour ces demandes.

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

Cluster principal Power BI (BE)

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

Le serveur principal est disponible dans la plupart des régions Azure et est déployé dans de nouvelles régions à mesure 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 principal 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 de cluster d’accueil d’un utilisateur authentifié sont fournies par le service global et utilisées par le serveur frontal web pour acheminer les demandes vers le cluster d’accueil du locataire.

Chaque cluster back-end se compose de plusieurs machines virtuelles combinées en plusieurs groupes identiques resizables 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 et les données du locataire sont stockées dans des limites de cluster, à l’exception de la réplication des données vers un cluster principal 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 micro-services 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 principal

infrastructure Power BI Premium

Power BI Premium offre un service pour les abonnés qui nécessitent des fonctionnalités Power BI premium, telles que dataflows, rapports paginés, IA, etc. Lorsqu’un client s’inscrit à un abonnement Power BI Premium, la capacité Premium est créée par le biais d’Azure Resource Manager.

Power BI Premium capacités sont hébergées dans des clusters principaux indépendants du back-end Power BI standard , voir ci-dessus). Cela offre une meilleure isolation, une allocation de ressources, une facilité de prise en charge, une isolation de sécurité et une scalabilité 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. Power BI Premium clients 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 majorité des ressources Premium sont encapsulées à l’intérieur d’un cluster (par exemple, le calcul) et il existe certaines ressources régionales courantes (par exemple, stockage de métadonnées). L’infrastructure Premium permet d’atteindre deux façons 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).

Le cœur principal de chaque cluster est les ressources de calcul gérées par des groupes de machines virtuelles identiques et Azure Service Fabric. Les groupes de machines virtuelles identiques et Service Fabric permettent une augmentation rapide et sans douleur 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.

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 à Azure AD exclusivement.

Toute demande qui vient à Power BI Premium infrastructure 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, le gèrent ou le transfèrent aux ressources appropriées (par exemple, les nœuds back-end).

Les nœuds principaux fournissent la plupart des fonctionnalités et fonctionnalités 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 relatives à la sécurité pour les applications Power BI Mobile se trouvent dans deux catégories :

  • Communication de l’appareil
  • L’application et les 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 montre la prise en charge de l’authentification par certificat (CBA) pour Power BI Mobile, en fonction de la plateforme d’appareils mobiles :

Prise en charge de l’administrateur de base de données iOS Android Windows
Power BI (connexion au service) Pris en charge Pris en charge Non prise en charge
SSRS ADFS local (connectez-vous au serveur SSRS) Non prise en charge Pris en charge Non prise en charge
Proxy d’application SSRS Prise en charge Pris en charge 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 facilite l’utilisation de l’application :

  • Les jetons d’actualisation et Azure AD 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, cela est automatiquement effectué lorsque l’utilisateur définit un code secret. Dans Android, cela peut être configuré dans les paramètres. Dans Windows, il est accompli à 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 qui est 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 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 résidence des données géographiques pour les notifications.

Le chiffrement des données peut être amélioré en appliquant le chiffrement au niveau du fichier 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. 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 Microsoft Intune.

L’application Windows prend également en charge Windows Information Protection (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 tierces Microsoft (telles que Microsoft Authenticator) et gérées par le Kit de développement logiciel (SDK) Azure Active Directory Authentication Library (ADAL).

Power BI Mobile les 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 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. En savoir plus sur l’identification supplémentaire.

Authentification au 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 flux d’octroi de code d’authentification d’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 de l’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 d’accueil 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. 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 le plus proche service Power BI le plus proche avec un code d’authentification.

  5. Le cluster WFE vérifie avec le service Azure AD pour obtenir un jeton de sécurité Azure AD à l’aide du code d’authentification. Quand Azure AD retourne l’authentification réussie de l’utilisateur et retourne un jeton de sécurité Azure AD, le cluster WFE consulte le service global Power BI, qui gère la liste des locataires et leurs emplacements de cluster back-end Power BI et détermine le cluster de service principal Power BI qui 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 Azure AD dans l’en-tête d’autorisation. Le cluster principal Power BI lit le jeton d’accès Azure AD et valide la signature pour vérifier 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 maintenir la session actuelle, le navigateur de l’utilisateur effectue des demandes périodiques pour renouveler le jeton d’accès avant son expiration.

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 affectée lorsqu’un locataire Azure AD s’inscrit pour la première fois aux services Power BI. 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 de données client est effectuée en mappant le pays ou la région sélectionné dans le cadre de la configuration du locataire Azure AD à la zone géographique Azure la plus appropriée où un déploiement Power BI existe. Une fois cette détermination effectuée, toutes les données client 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éographique)

Certaines organisations ont une présence mondiale et peuvent nécessiter des services Power BI dans plusieurs zones géographiques Azure. Par exemple, une entreprise peut avoir son siège social dans le É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 respecter les réglementations locales. Cette fonctionnalité du service Power BI est appelée multigéographique.

La couche d’exécution de requête, les caches de requêtes et les données d’artefact affectées à un espace de travail multigéographique sont hébergés et restent dans la zone géographique Azure de 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 d’accueil du locataire. En outre, certains transits et traitement des données peuvent toujours se produire dans la zone géographique d’accueil du locataire, même pour les espaces de travail hébergés dans une capacité Premium multigéographique.

Consultez Configurer la prise en charge multigéographique pour Power BI 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.

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 relatifs à l’emplacement des données client au repos sont spécifiés dans les conditions de traitement des données des conditions des services en ligne Microsoft.

Microsoft fournit également des centres de données pour les entités souverains. 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 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 SQL Azure

Dans la majorité 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 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 TDE (Transparent Data Encryption) de Azure SQL. Les données client stockées dans le stockage Blob Azure sont chiffrées à l’aide d’Azure Storage Encryption.

Éventuellement, les organisations peuvent utiliser Power BI Premium pour utiliser leurs propres clés pour 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 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 être facilement obtenu à l’aide du chiffrement côté service transparent. Pour plus d’informations, consultez Apportez vos propres clés de chiffrement pour Power BI .

Les jeux de données Power BI permettent de divers 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 jeu de données (type) 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 S’il est configuré pour conserver

Quel que soit le mode de jeu de données utilisé, Power BI peut mettre en cache temporairement toutes les données récupérées 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 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 qui tentent d’utiliser le service avec TLS 1.1 ou une version antérieure sont 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 basée sur 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 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 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 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. Lorsqu’il est utilisé 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 Azure AD est utilisée pour l’authentification unique ; pour les sources de données locales, Kerberos, Security Assertion Markup Language (SAML) et Azure AD sont pris en charge.

Si la source de données est Azure Analysis Services ou locale Analysis Services, et que la sécurité au niveau des lignes et/ou OLS est configurée, le service Power BI applique cette sécurité au niveau des lignes 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 verront 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 dataflow. 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 dataflow a été créé, tout membre, contributeur ou administrateur de l’espace de travail peut planifier des actualisations, ainsi que l’affichage et la modification du dataflow 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 Power Query services pendant que les données sont en cours d’exécution. Pour les flux de données Premium, Power Query services 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 dans le traitement 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 la section Authentification auprès des 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 détenu par Power BI. Le chiffrement de stockage 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 au repos ci-dessous. Toutefois, les utilisateurs peuvent configurer leur propre compte de stockage associé à leur propre abonnement Azure. Dans ce cas, un principal 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 de stockage ADLS 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 deux fois.

Lors de l’interrogation à l’aide de DirectQuery, le protocole de transport chiffré HTTPS 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 décrits précédemment. Étant donné que les dataflows 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 d’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 dataflow, il doit d’abord authentifier l’utilisateur à l’aide d’Azure AD 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 au stockage directement à l’aide du protocole de transport chiffré HTTPS.

Le traitement des données dans tout 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 ayant 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 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 vers le cluster Power BI Premium.

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

Rapports paginés Gen 1

Pour Premium Gen2, un bac à sable éphémère individuel et exclusif est créé pour chacun des rendus d’un rapport, fournissant un niveau d’isolation plus élevé entre les utilisateurs.

Rapports paginés Gen 2

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 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 à un secret.

Pour prendre en charge des fonctionnalités telles que des cartes Bing ou des appels à Azure Functions, le bac à sable 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 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 incorporé pour votre organisation , les utilisateurs Azure AD accèdent à leur propre contenu Power BI via des portails personnalisés par leurs entreprises et leurs IT. Toutes les stratégies et fonctionnalités Power BI décrites dans ce document, telles que la 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 de l’accès à Power BI via le portail Power BI ou via des portails personnalisés.

Dans un scénario incorporé pour vos clients , les éditeurs de logiciels indépendants possèdent généralement des locataires Power BI et des artefacts Power BI (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 à 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’ÉDITEUR de logiciels indépendants. Les utilisateurs finaux qui utilisent un navigateur ou d’autres applications clientes ne peuvent pas déchiffrer ou modifier des jetons incorporés. Les kits SDK côté client tels que les API clientEs Power BI ajoutent automatiquement le jeton incorporé chiffré aux requêtes Power BI en tant qu’autorisation : en-tête EmbedToken . En fonction de cet en-tête, Power BI applique toutes les stratégies (telles que l’accès ou la sécurité au niveau des lignes) exactement comme spécifié par l’éditeur de logiciels indépendants pendant la génération.

Pour activer l’incorporation et l’automatisation et 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 Azure AD 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 : par exemple, les balises de service et les liaisons privées.

Fonctionnalités d’IA

Power BI prend actuellement en charge deux grandes catégories de fonctionnalités IA dans le produit aujourd’hui : visuels IA et enrichissements ia. Les fonctionnalités d’IA au niveau visuel incluent des fonctionnalités telles que key-Influenceurs, Decomposition-Tree, Smart-Narrative, Anomalie-Detection, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights etc. Les fonctionnalités d’enrichissement ia incluent des fonctionnalités telles que AutoML, AzureML, CognitiveServices, R/Python transforms, etc.

La plupart des fonctionnalités mentionnées ci-dessus sont prises en charge dans les espaces de travail Partagé 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 ML personnalisé (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 Power BI peuvent appliquer plusieurs API CognitiveServices, telles que TextAnalytics et ImageTagging, pour transformer des données avant de les charger dans un dataflow/dataset défini dans un espace de travail Premium.

Les fonctionnalités d’enrichissement d’IA Premium peuvent être vues comme 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 jeu de données Power BI ou un dataflow. Notez que ces fonctions sont également accessibles à partir d’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/transformations IA s’exécutent toujours dans un espace de travail/capacité Premium. Ces fonctions sont exposées dans Power BI comme source de données qui nécessite un jeton Azure AD 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 individuellement les scénarios Premium pour comprendre les modèles de communication et les détails pertinents liés à la sécurité qui leur sont associés.

Pour l’apprentissage 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’apprentissage, Power BI appelle un service AzureML 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, la précision, l’algorithme ml, les paramètres d’algorithme, etc.) de l’itération précédente sont envoyées. L’entraînement 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 Power BI peuvent ensuite appliquer le modèle ML entraîné comme transformation pour opérationnaliser le modèle ML sur une base planifiée. Pour les API TextAnalytics et ImageTagging, Power BI n’appelle pas directement les API du service CognitiveServices, 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 dataflows et les jeux de données Power BI. Lors de la création d’un jeu 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 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 licence. 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é. 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 des 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 la balise 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’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 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 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 Azure, telle que l’accès local, exigerait que les clients aient configuré ExpressRoute ou un réseau privé virtuel (VPN).

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

Connectivité de réseau virtuel (préversion - bientôt disponible)

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 de sécuriser la connectivité sortante 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 d’installation et de 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 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 lorsque 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.

Cette fonctionnalité sera bientôt disponible en préversion publique.

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 Key Vault, 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 les tâches d’espace de travail et de jeu de données Premium avec des principaux de service .

Microsoft Purview pour Power BI

Protection des informations Microsoft Purview

Power BI est profondément intégré à Microsoft Perview Information Protection (précédemment Microsoft 365 Compliance Information Protection). Protection des données Microsoft Purview 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 Excel, PowerPoint, PDF, Word ou .pbix , pour vous assurer que les données sont protégées même quand 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 marqués en fonction de leur niveau de sensibilité. De plus, ils peuvent être chiffrés s’ils contiennent des données confidentielles métier, ce qui garantit que seuls les utilisateurs autorisés peuvent modifier ces fichiers.
  • Les classeurs Excel héritent automatiquement des étiquettes de confidentialité lorsqu’ils se connectent à Power BI (préversion), ce qui permet de maintenir la classification de bout en bout et d’appliquer la protection lorsque les jeux de données 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 à l’exportation lors de l’incorporation du contenu Power BI.
  • L’héritage des étiquettes lors de la création de contenu dans l’service Power BI garantit que les étiquettes appliquées aux jeux de données ou aux datamarts dans le service Power BI seront appliquées au nouveau contenu créé en plus de ces jeux de données et 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 dans le service Power BI.
  • Les équipes centrales peuvent créer des stratégies d’étiquette 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 confidentialité en aval dans le service Power BI garantit que lorsqu’une étiquette sur un jeu de données 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 jeu de données ou au datamart.

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

stratégies Protection contre la perte de données Microsoft Purview (DLP) pour Power BI (préversion)

Les stratégies DLP de Microsoft Purview peuvent aider les organisations à réduire le risque de fuite de données métier sensibles à partir de Power BI. Les stratégies DLP peuvent les aider à respecter les exigences de conformité des réglementations gouvernementales ou industrielles, telles que le RGPD (règlement général sur la protection des données) de l’Union européenne ou le CCPA (California Consumer Privacy Act) et s’assurer que leurs données dans Power BI sont gérées.

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

  • Tous les jeux de données au sein des 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 :
    • Les étiquettes de confidentialité.
    • Types d’informations sensibles. Plus de 260 types sont pris en charge. La détection des types d’informations sensibles s’appuie sur l’analyse du contenu Microsoft Purview.
  • Lorsque vous rencontrez un jeu de données 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 jeu de données, vous pouvez remplacer une stratégie et empêcher votre jeu de données d’être identifié comme étant « sensible » si vous avez une raison valide de le faire.
  • Si vous êtes propriétaire d’un jeu de données, vous pouvez signaler un problème avec une stratégie si vous concluez qu’un type d’informations sensibles a été faussement identifié.
  • Les atténuations automatiques des risques, telles que les alertes à l’administrateur de sécurité, peuvent être appelées.

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

Microsoft Defender for Cloud Apps pour Power BI

Microsoft Defender for Cloud Apps est l’un des principaux courtiers en 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 cloud (CASB). Defender pour Cloud Apps 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 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 utilisateur, 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, la session peut être surveillée par les contrôles en temps réel Defender pour Cloud Apps et les actions risquées, telles que le téléchargement de données étiquetées avec une étiquette de confidentialité « Hautement confidentielle », peuvent être bloquées immédiatement.
  • Examinez l’activité utilisateur Power BI avec le journal d’activité Defender pour Cloud Apps. Le journal d’activité Defender pour Cloud Apps inclut l’activité Power BI telle que capturée dans le journal d’audit Office 365, qui contient des informations sur toutes les activités utilisateur et d’administration, ainsi que des informations sur l’étiquette de confidentialité pour les activités pertinentes telles que l’application, la modification et la suppression d’étiquette. 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 peut-être 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 des analyses comportementales et du machine learning utilisateur prêtes à l’emploi dès le début pour 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 de contrôles Microsoft Defender for Cloud Apps dans Power BI.

Fonctionnalités de sécurité en préversion

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

Bring Your Own Log Analytics (BYOLA)

Bring Your Own Log Analytics permet l’intégration entre Power BI et Azure Log Analytics. Cette intégration inclut le moteur analytique avancé d’Azure Log Analytics, le langage de requête interactif et les constructions de Machine Learning intégrées.

Questions et réponses sur la sécurité Power BI

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

  • Power BI gère les informations d’identification vers des 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 de ces sources de données peuvent être gérées par la passerelle Administration. 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 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 le tableau de bord n’accède pas à la source de données sous-jacente. Power BI prend en charge l’authentification par 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 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, 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, 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 Azure AD est utilisée pour l’authentification unique; pour les sources de données locales, Kerberos, SAML et Azure AD sont pris en charge.

    Lors de la connexion avec Kerberos, l’UPN de l’utilisateur est passé à la passerelle et à l’aide de la délégation contrainte Kerberos, l’utilisateur est emprunt d’identité 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 en local Analysis Services et la sécurité au niveau des lignes (RLS) et/ou la sécurité au niveau de l’objet (OLS), le service Power BI applique cette sécurité au niveau des lignes 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 voit pas les données pour lequel l’utilisateur n’a 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 limitent l’accès aux données au niveau de la ligne et vous pouvez définir des filtres dans le rôle.

    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’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 simplement.

    La sécurité au niveau de l’objet, ainsi que la sécurité au niveau des lignes, permet d’améliorer la sécurité de niveau entreprise sur les rapports et les jeux de données, en garantissant que seuls les utilisateurs disposant des autorisations requises ont accès à afficher et interagir avec des 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 à 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 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é en fonction du rôle, du partage de rapports ou de tableaux de bords et des connexions de données ? Quel est le principe de fonctionnement 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 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 établies à une source de données compatible RLS, 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 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 aux sources de données plus haut dans ce document.

Nos utilisateurs se connectent toujours aux mêmes sources de données, dont certaines nécessitent des informations d’identification qui diffèrent de leurs informations d’identification de domaine. Comment éviter qu’ils ne doivent entrer ces informations d’identification chaque fois qu’ils établissent 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 ? Y a-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 dans le lien suivant : ports de passerelle

En cas d’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 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 nécessite que les ports 443, 5671-5672 et 9350-9354 soient ouverts 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 de la 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 inclut 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, pendant la durée de la session de navigateur 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 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 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 responsable de l’information du client sur le comportement et les fonctionnalités de l’application.

Qu’en est-il de la souveraineté des données ? Pouvons-nous provisionner des locataires dans des centres de données situés dans des zones géographiques spécifiques, afin de nous assurer que les données ne quittent pas les frontières 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.

    Vous pouvez é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. 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 les connexions pour les clients disposant d’abonnements Power BI Premium ? Ces connexions sont-elles différentes de celles créées 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 Azure Business-to-Business (B2B), à l’aide d’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.

Ressources supplémentaires

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