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 modèles sémantiques (anciennement appelés jeux de données) et des visualisations de décisionnel 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.

Scénaristes : 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, Analytics incorporée Power BI, Power BI Mobile.

Remarque

Vous pouvez enregistrer ou imprimer ce white paper en sélectionnant Imprimer dans votre navigateur, puis en sélectionnant Enregistrer au format PDF.

Présentation

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 modèles sémantiques et des visualisations décisionnels 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 traversent une transformation numérique accélérée, et nous constatons une augmentation massive du travail à distance, une demande accrue des clients pour les services en ligne et une utilisation accrue des technologies avancées dans les opérations et la prise de décision commerciale. Et tout cela est alimenté par le cloud.

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

Les fondations vieilles de plusieurs décennies du modèle de sécurité BI – la sécurité au niveau des objets et des lignes – bien qu'elles soient toujours importantes, ne suffisent manifestement plus à fournir le type de sécurité nécessaire à l'ère du cloud. Au lieu de cela, les entreprises doivent rechercher une solution de sécurité cloud native, à plusieurs niveaux et de défense en profondeur pour leurs données de Business Intelligence.

Power BI a été conçu pour fournir une protection complète et hermétique des données à la pointe de l'industrie. Le produit a obtenu 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 prestataires de soins de santé lui confient leurs informations les plus sensibles.

Tout commence par la fondation. Après une période difficile au début des années 2000, Microsoft a fait des investissements massifs pour remédier à ses vulnérabilités de sécurité et, au cours des décennies suivantes, a construit une pile de sécurité solide qui va aussi loin que le noyau bios sur puce de la machine et s'étend jusqu'à la fin. expériences des utilisateurs. Ces investissements considérables se poursuivent et aujourd'hui, plus de 3 500 ingénieurs Microsoft sont engagés dans la construction et l'amélioration de la pile de sécurité de Microsoft et dans la lutte proactive contre le paysage des menaces en constante évolution. Avec des milliards d'ordinateurs, des billions de connexions et d'innombrables zettaoctets d'informations confiés à la protection de Microsoft, l'entreprise possède désormais la pile de sécurité la plus avancée de l'industrie technologique et est largement considérée comme le leader mondial de la lutte contre les acteurs malveillants.

Power BI s'appuie sur cette base solide. Il utilise la même pile de sécurité qui a valu à Azure le droit de servir et de protéger les données les plus sensibles au monde, et il s'intègre aux outils de protection et de conformité des informations 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 se traduit par une protection de bout en bout conçue pour faire face aux défis uniques de l'ère du cloud.

Pour fournir une solution de bout en bout pour la protection des actifs sensibles, l'équipe produit devait répondre aux préoccupations difficiles des clients sur plusieurs fronts simultanés :

• Comment contrôlons-nous qui peut se connecter, 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 crypté ?Quels contrôles ai-je sur mes données ?
• Comment contrôler et protéger mes données sensibles ?Comment puis-je m'assurer que ces données ne peuvent pas fuir en dehors de l'organisation ?
• Comment auditer qui effectue quelles opérations ?Comment réagir rapidement en cas d'activité suspecte sur le service ?

Cet article apporte une réponse complète à toutes ces questions. Il commence par une vue d'ensemble de l'architecture du service et explique le fonctionnement des principaux flux du système. Il décrit 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 connaître l'emplacement du traitement des données, reportez-vous aux conditions relatives à l'emplacement du traitement des données dans les Conditions des Services en Ligne Microsoft 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 du développement de la sécurité (SDL), des pratiques de sécurité strictes qui prennent en charge les exigences de sécurité et de conformité. Le SDL aide les développeurs à créer des logiciels plus sécurisés en réduisant le nombre et la gravité des vulnérabilités des logiciels, tout en réduisant les coûts de développement. Pour en savoir plus, consultez Pratiques Microsoft Security Development Lifecycle.

Architecture Power BI

Le service Power BI est construit sur Azure, la plateforme de 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.

Cluster Web frontal (WFE)

Le cluster WFE fournit au navigateur de l'utilisateur le contenu initial de la page HTML lors du chargement du site et des pointeurs vers le contenu CDN utilisé pour afficher le site dans le navigateur.

Un cluster WFE se compose d'un site Web ASP.NET s'exécutant dans l'Azure App Service Environment. 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 Méthode de routage du trafic de performance pour Azure Traffic Manager.

Les ressources statiques telles que *.js, *.css et les fichiers image sont principalement stockées sur un réseau de diffusion de contenu Azure (CDN) et récupérées directement par le navigateur. Notez que les déploiements de clusters de gouvernement souverain sont une exception à cette règle et, pour des raisons de conformité, omettent le CDN et utilisent à la place un cluster WFE d'une région conforme pour l'hébergement de contenu statique.

Cluster principal Power BI (BE)

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

Le back-end est disponible dans la plupart des régions Azure et est déployé dans de nouvelles régions au fur et à mesure de leur disponibilité. Une seule région Azure héberge un ou plusieurs clusters principaux qui permettent 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 sur le cluster d'accueil d'un utilisateur authentifié sont fournies par Global Service et utilisées par Web Front End 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 ensembles redimensionnables adapté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 les limites du 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.

La fonctionnalité back-end est servie par des micro-services s'exécutant sur différentes machines du réseau virtuel du cluster qui ne sont pas accessibles de l'extérieur, à l'exception de deux composants accessibles depuis l'Internet public :

• Service de passerelle
• Gestion des API Azure

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 l’IA avancée, la distribution aux utilisateurs sans licence, etc. Lorsqu’un client souscrit à un abonnement Power BI Premium, la capacité Premium est créée via Azure Resource Manager.

Les capacités Power BI Premium sont hébergées dans des clusters back-end indépendants du back-end Power BI standard – voir ci-dessus). Cela permet d'améliorer l'isolation, l'allocation des ressources, la prise en charge, l'isolement de la sécurité et l'évolutivité de l'offre Premium.

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

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

L'infrastructure Power BI Premium dans une région Azure se compose de plusieurs clusters Power BI Premium (le minimum est un). La plupart des ressources Premium sont encapsulées dans un cluster (par exemple, le calcul), et il existe des ressources régionales communes (par exemple, le stockage des métadonnées). L'infrastructure Premium permet deux façons d'atteindre l'évolutivité horizontale dans une région : augmenter les ressources à l'intérieur des clusters et/ou ajouter plus de clusters à la demande selon les besoins (si les ressources du cluster approchent de leurs limites).

L'épine dorsale de chaque cluster est constituée de ressources de calcul gérées par des groupes de machines virtuelles identiques et Azure Service Fabric. Microsoft Azure Virtual Machine Scale Sets et Service Fabric permettent une augmentation rapide et simple des nœuds de calcul à mesure que l'utilisation augmente et orchestrent le déploiement, la gestion et la surveillance des services et applications Power BI Premium.

De nombreuses ressources environnantes garantissent une infrastructure sécurisée et fiable : équilibreurs de charge, réseaux virtuels, groupes de sécurité réseau, bus de service, 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 exclusivement via une intégration à Microsoft Entra ID (précédemment appelé Azure Active Directory).

Toute requête envoyée à l'infrastructure Power BI Premium est d'abord dirigée vers les nœuds frontaux – ce sont les seuls nœuds disponibles pour les connexions externes. Le reste des ressources est caché derrière des réseaux virtuels. Les nœuds frontaux authentifient la requête, la traitent ou la transfèrent aux ressources appropriées (par exemple, les nœuds principaux).

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

Power BI Mobile

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

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

Pour la communication avec les 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 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 ouvrent une session de navigateur dans l'application elle-même, tandis que l'application mobile Windows affiche un courtier 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 de l'appareil mobile :

Prise en charge de CBA	iOS	Android	Windows
Power BI (connexion au service)	Prise en charge	Prise en charge	Non pris en charge
SSRS ADFS sur site (se connecter au serveur SSRS)	Non pris en charge	Prise en charge	Non pris en charge
Proxy d’application SSRS	Pris 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 recueillir 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 facilitent l'utilisation de l'application :

• Microsoft Entra ID et les jetons d’actualisation sont stockés dans un mécanisme sécurisé sur l’appareil en utilisant des mesures de sécurité standard du secteur d’activité.
• 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 se fait automatiquement lorsque l'utilisateur définit un mot de passe. Sous Android, cela peut être configuré dans les paramètres. Sous Windows, cela se fait à l'aide de BitLocker.
• Pour les applications Android et iOS, les données et les paramètres (paires clé-valeur pour la configuration de l'utilisateur) sont mis en cache dans le stockage sur l'appareil dans un sandbox et un stockage interne accessible uniquement à l'application. Pour l'application Windows, les données ne sont accessibles que par l'utilisateur (et l'administrateur système).
• Le service Geolocation 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 un chiffrement au niveau des fichiers via Microsoft Intune, un service logiciel qui fournit la gestion des appareils mobiles et des applications. Les trois plates-formes pour lesquelles Power BI Mobile est disponible prennent en charge Intune. Avec Intune activé et configuré, les données sur l'appareil mobile sont chiffrées et l'application Power BI elle-même ne peut pas être installée sur une carte SD. En savoir plus sur Microsoft Intune.

L'application Windows prend également en charge la Microsoft Azure Information Protection (WIP).

Afin de mettre en place 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 sont gérées par la Bibliothèque d’authentification Microsoft (MSAL).

Les données mises en cache de Power BI Mobile sont supprimées lorsque l'application est supprimée, lorsque l'utilisateur se déconnecte de Power BI Mobile ou lorsque l'utilisateur ne parvient pas à se connecter (par exemple après un événement d'expiration de jeton ou un changement 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 aux 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 une identification supplémentaire, comme fournir Face ID, Touch ID ou un mot de passe pour iOS, et des données biométriques (Fingerprint ID) 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 des utilisateurs dans Power BI qui suit le flux d’octroi de code d’authentification de Microsoft Entra. Pour plus d'informations sur les options des modèles d'authentification des utilisateurs d'une organisation (modèles de connexion), voir Choisir un modèle de connexion pour Microsoft 365.

Séquence d’authentification

La séquence d'authentification de l'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 initie une connexion au service Power BI à partir d'un navigateur, soit en saisissant l'adresse Power BI dans la barre d'adresse, soit en sélectionnant Se connecter à partir de la page marketing Power BI (https://powerbi.microsoft.com). La connexion est établie à l'aide de TLS et HTTPS, et toutes les communications ultérieures entre le navigateur et le service Power BI utilisent HTTPS.

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

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

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

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

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

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

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

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

Résidence des données

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

L’affectation d’une géographie Azure pour le stockage des données du tenant est effectuée en mappant le pays ou la région sélectionné dans le cadre de la configuration du tenant Microsoft Azure dans la géographie 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 seront stockées dans cette zone géographique Azure sélectionnée (également appelée zone géographique d'accueil), sauf dans les cas où les organisations utilisent des déploiements multi-géo.

Géographies multiples (multi-géo)

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 aux États-Unis, mais peut également faire des affaires dans d'autres zones géographiques, comme l'Australie. Dans de tels cas, l'entreprise peut exiger que certaines données Power BI restent stockées au repos dans la région distante pour se conformer aux réglementations locales. Cette fonctionnalité du service Power BI est appelée multi-geo.

La couche d'exécution des requêtes, les caches de requêtes et les données d'artefact attribuées à un espace de travail multigéographique sont hébergées et restent dans la géographie Azure à capacité distante. Cependant, certaines métadonnées d'artefact, telles que la structure du rapport, peuvent rester stockées au repos dans la géolocalisation du locataire. De plus, certains transits et traitements de données peuvent encore 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 multi-géo.

Consultez Configurer la prise en charge de plusieurs zones géographiques pour Power BI Premium pour plus d'informations sur la création et la gestion de 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, 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 des Services en Ligne Microsoft.

Microsoft fournit également des centres de données pour les entités souveraines. Pour plus d'informations sur la disponibilité du service Power BI pour les clouds nationaux/régionaux, voir Clouds nationaux/régionaux Power BI.

Gestion des données

Cette section décrit les pratiques de gestion des données Power BI en matière de stockage, de traitement et de transfert des données client.

Données au repos

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

• Stockage Azure
• Bases de données Azure SQL

Dans la plupart des scénarios, Stockage Microsoft 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 des artefacts.

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 Azure SQL Databases sont entièrement chiffrées à l'aide de la technologie Transparent Data Encryption (TDE) d'Azure SQL. Les données client stockées dans Stockage Microsoft Azure Blob sont chiffrées à l'aide d'Stockage Microsoft Azure Encryption.

En option, les organisations peuvent utiliser Power BI Premium pour utiliser leurs propres clés afin de chiffrer les données au repos importées dans un modèle sémantique. 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 de l'opérateur de service, les données client ne seront pas exposées – ce qui ne peut pas être facilement réalisé en utilisant un chiffrement transparent côté service. Voir Apporter vos propres clés de chiffrement pour Power BI pour plus d'informations.

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

Mode modèle sémantique (genre)	Données persistantes dans Power BI
Importer	Oui
DirectQuery	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 modèle sémantique utilisé, Power BI peut temporairement mettre en cache toutes les données récupérées pour optimiser les performances de chargement des requêtes et des rapports.

Données en cours de traitement

Les données sont en cours de traitement lorsqu'elles sont activement utilisées par un ou plusieurs utilisateurs dans le cadre d'un scénario interactif ou lorsqu'un processus d'arrière-plan, tel qu'une actualisation, touche ces données. Power BI charge les données activement traitées 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 en mémoire ne sont pas chiffrées.

Données en transit

Power BI exige que tout le trafic HTTP entrant soit chiffré à l'aide de TLS 1.2 ou supérieur. Toute demande tentant d'utiliser le service avec TLS 1.1 ou inférieur sera rejetée.

Authentification aux sources de données

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

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

Si une source de données est connectée directement à l'aide d'informations d'identification préconfigurées, les informations d'identification préconfigurées sont utilisées pour se connecter à la source de données lorsqu'un utilisateur affiche les données. Si une source de données est connectée directement à l'aide de l'authentification unique, les informations d'identification de l'utilisateur actuel sont utilisées pour se connecter à la source de données lorsqu'un utilisateur affiche les données. Lorsqu'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 auxquelles ils ont des privilèges d'accès. Lorsque la connexion est établie avec des sources de données dans le cloud, l’authentification Microsoft Entra est utilisée pour l’authentification unique ; pour des sources de données locales, Kerberos, Security Assertion Markup Language (SAML) et Microsoft Entra ID sont pris en charge.

Si la source de données est Azure Analysis Services ou Analysis Services sur site, et que RLS et/ou OLS sont configurés, le service Power BI appliquera 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 peut être une requête utilisée dans un tableau de bord, un rapport ou un autre artefact de données) ne verra pas les données pour lesquelles ils ne disposent pas de privilèges suffisants.

Fonctionnalités Premium

Architecture des flux de données

Les flux de données offrent aux utilisateurs la possibilité de configurer des opérations de traitement de données back-end qui extraient des données de sources de données polymorphes, exécutent une logique de transformation sur les données, puis les placent dans un modèle cible à utiliser dans diverses technologies de présentation de rapports. Tout utilisateur ayant 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 ayant le rôle de visualiseur peuvent afficher les données traitées par le flux de données mais ne peuvent pas modifier leur 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 que visualiser et modifier le flux de données en s'en appropriant.

Chaque source de données configurée est liée à une technologie client pour accéder à cette source de données. La structure des informations d'identification requises pour y accéder est formée pour correspondre aux détails d'implémentation requis de la source de données. La logique de transformation est appliquée par les services Power Query pendant que les données sont en vol. Pour les flux de données premium, les services Power Query s'exécutent dans des nœuds principaux. Les données peuvent être extraites directement des sources cloud ou via une passerelle installée sur site. Lorsqu'il est tiré directement d'une source cloud vers le service ou vers la passerelle, le transport utilise une 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 cryptées. Voir la section Données en transit ci-dessus.

Lorsque les sources de données spécifiées par le client nécessitent des informations d'identification pour l'accès, le propriétaire/créateur du flux de données les fournira lors de la création. Ils sont stockés à l'aide d'un stockage d'informations d'identification standard à l'échelle du produit. Voir la section Authentification aux 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 détenu et protégé par Power BI. Le chiffrement du stockage est activé sur les conteneurs de stockage Blob pour protéger les données lorsqu'elles sont au repos. Voir la section Données au repos ci-dessous. Les utilisateurs peuvent toutefois configurer leur propre compte de stockage associé à leur propre abonnement Azure. Ce faisant, un principal de service Power BI se voit accorder l'accès à ce compte de stockage afin qu'il puisse y écrire les données lors de 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 être sous-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 un accès par le système Power BI principal. Les données sont toujours crypté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 les chiffrer doublement.

Lors d'une requête à 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 flux de données sont toujours liés à un espace de travail, l'accès aux données est toujours limité par le rôle de l'utilisateur dans cet espace de travail. Un utilisateur doit avoir au moins un accès en lecture pour pouvoir interroger les données par n'importe quel moyen.

Lorsque Power BI Desktop est utilisé pour accéder aux données dans un flux de données, l’application doit d’abord authentifier l’utilisateur en tirant parti de Microsoft Entra ID pour déterminer si l’utilisateur dispose de droits suffisants pour afficher les données. Si tel 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 tout au long du pipeline émet des événements d'audit Office 365. Certains de ces événements captureront des 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. Vous pouvez contrôler exactement la disposition de la page des rapports.

Les rapports paginés prennent en charge des expressions riches et puissantes écrites en Microsoft Visual De base .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 accès au large éventail de fonctionnalités du framework .NET. 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é (.rdl) sont stockées dans Power BI, et pour publier et/ou rendre un rapport paginé, un utilisateur doit s'authentifier et autoriser de la même manière que celle décrite dans la section Authentification au service Power BI ci-dessus.

Le jeton Microsoft Entra obtenu lors de l’authentification est utilisé pour communiquer directement du navigateur au cluster Power BI Premium.

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

Un rapport paginé peut accéder à un large ensemble de sources de données dans le cadre du rendu du rapport. Le bac à sable ne communique directement avec aucune des 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 à aucun identifiant ou secret.

Afin de prendre en charge des fonctionnalités telles que les cartes Bing ou les 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 disposent de deux modes principaux d'intégration d'artefacts Power BI dans leurs applications et portails Web : intégration pour votre organisation et intégration pour vos clients. L'artefact est intégré 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 ou du portail externe, et la communication avec l'IFrame est effectuée à l'aide du SDK client Power BI à l'aide de messages POST.

Dans un scénario d’intégration pour votre organisation, les utilisateurs de Microsoft Entra accèdent à leur propre contenu Power BI via des portails personnalisés par leur entreprise et leur service informatique. 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 des objets (OLS), sont automatiquement appliquées à tous les utilisateurs, qu'ils accèdent à 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 éléments Power BI (tableaux de bord, rapports, modèles sémantiques et autres). C'est la responsabilité d'un service back-end ISV d'authentifier ses utilisateurs finaux et de décider quels artefacts et quel niveau d'accès sont appropriés pour cet utilisateur final. Les décisions de politique ISV sont chiffrées dans un jeton intégré généré par Power BI et transmis au back-end ISV pour une distribution ultérieure aux utilisateurs finaux conformément à la logique métier de l'ISV. Les utilisateurs finaux utilisant un navigateur ou d'autres applications clientes ne peuvent pas déchiffrer ou modifier les jetons intégrés. Les SDK côté client tels que les API client Power BI ajoutent automatiquement le jeton d'intégration chiffré aux requêtes Power BI en tant qu'en-tête Authorization: EmbedToken. Sur la base de cet en-tête, Power BI appliquera toutes les stratégies (telles que l'accès ou RLS) précisément comme cela a été spécifié par l'ISV lors de la génération.

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

L’analytiques 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 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 actuel : les visuels d'IA et les enrichissements d'IA. Les fonctionnalités AI au niveau visuel comprennent des fonctionnalités telles que Influenceurs clés, Arborescence hiérarchique, Narration intelligente, Détection d’anomalie, Visuel R, Visuel Python, Clustering, Prévisions, Q&A, Quick-Insights, etc. Les fonctionnalités d’enrichissement par IA comprennent celles telles qu’AutoML, Azure Machine Learning, CognitiveServices, transformations R/Python, etc.

La plupart des fonctionnalités mentionnées ci-dessus sont actuellement prises en charge dans les espaces de travail partagés et Premium. Toutefois, AutoML et CognitiveServices ne sont pris en charge que dans les espaces de travail Premium, en raison de restrictions IP. Aujourd'hui, avec l'intégration d'AutoML dans Power BI, un utilisateur peut créer et former 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. . De plus, les utilisateurs de Power BI peuvent appliquer plusieurs API CognitiveServices, telles que TextAnalytics et ImageTagging, pour transformer les données avant de les charger dans un flux de données/modèle sémantique défini dans un espace de travail Premium.

Les fonctionnalités d'enrichissement de l'IA Premium peuvent être mieux considérées comme un ensemble de fonctions/transformations d'IA sans état pouvant être utilisées par les utilisateurs de Power BI dans leurs pipelines d'intégration de données utilisés par un modèle sémantique 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/de modèles sémantiques actuels dans le service Power BI et Power BI Desktop. Ces fonctions/transformations IA s'exécutent toujours dans un espace de travail/une capacité Premium. Ces fonctions sont présentées dans Power BI en tant que source de données qui nécessite un jeton Microsoft Entra pour l’utilisateur Power BI qui utilise la fonction d’intelligence artificielle. Ces sources de données AI sont spéciales car elles ne font apparaître aucune de leurs propres données et ne fournissent que ces fonctions/transformations. Pendant l'exécution, ces fonctionnalités n'effectuent aucun appel sortant vers d'autres services pour transmettre les données du client. Examinons les scénarios Premium individuellement pour comprendre les modèles de communication et les détails pertinents liés à la sécurité qui les concernent.

Pour former et appliquer un modèle AutoML, Power BI utilise le SDK Azure AutoML et exécute toute la formation dans la capacité Power BI du client. Pendant les itérations de formation, Power BI appelle un Azure Machine Learning service d'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érience pertinentes (par exemple, précision, algorithme ml, 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 de formation qui sont ensuite enregistrées dans le flux de données. Plus tard, les utilisateurs de Power BI peuvent ensuite appliquer le modèle ML formé en tant que transformation pour opérationnaliser le modèle ML de manière planifiée. Pour les API TextAnalytics et ImageTagging, Power BI n'appelle pas directement les API de service CognitiveServices, mais utilise plutôt un SDK interne pour exécuter les API dans la capacité Power BI Premium. Aujourd'hui, ces API sont prises en charge dans les flux de données et les modèles sémantiques Power BI. Lors de la création d'un modèle de données dans Power BI Desktop, les utilisateurs ne peuvent accéder à cette fonctionnalité que s'ils ont accès à un espace de travail Premium Power BI. Par conséquent, les clients sont invités à fournir leurs informations d’identification Microsoft Entra.

Isolement réseau

Cette section décrit les fonctionnalités de sécurité avancées dans Power BI. Certaines des fonctionnalités ont des exigences de licence spécifiques. Voir les sections ci-dessous pour plus de détails.

Balises de service

Une balise de service représente un groupe de préfixes d’adresses IP d’un service Azure donné. Il aide à minimiser la complexité des mises à jour fréquentes des règles de sécurité du réseau. Les clients peuvent utiliser des balises de service pour définir des contrôles d'accès au 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 la balise de service (tel que PowerBI) dans le champ source ou 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.

Intégration de liaisons privées

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 dorsale de Microsoft, et les données ne traversent donc pas Internet.

Private Link garantit que les utilisateurs de Power BI utilisent le réseau principal du réseau privé Microsoft lorsqu'ils accèdent aux ressources du service Power BI.

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

• Private Link garantit que le trafic circulera sur le backbone Azure vers un point de terminaison privé pour les ressources basées sur le cloud Azure.
• L'isolation du trafic réseau de l'infrastructure non basée sur Azure, comme l'accès sur site, nécessiterait que les clients aient configuré ExpressRoute ou un réseau privé virtuel (VPN).

Voir Liens privés pour accéder à Power BI pour plus d'informations.

Connectivité VNet (préversion – bientôt disponible)

Alors que la fonctionnalité d'intégration Private Link fournit des connexions entrantes sécurisées à Power BI, la fonctionnalité de connectivité VNet permet une connectivité sortante sécurisée de Power BI aux sources de données au sein d'un réseau virtuel.

Les passerelles de réseau virtuel (gérées par Microsoft) élimineront les frais généraux liés à l'installation et à la surveillance des passerelles de données sur site pour la connexion aux sources de données associées à un réseau virtuel. Cependant, ils suivront toujours le processus familier de gestion de la sécurité et des sources de données, comme avec une passerelle de données sur site.

Voici un aperçu de ce qui se passe lorsque vous interagissez avec un rapport Power BI qui est connecté à une source de données dans un réseau virtuel à l'aide de passerelles 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 Power Platform VNet (PP VNet).

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

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

4. La passerelle VNet obtient la requête et se connecte aux sources de données avec ces informations d'identification.

5. La requête est alors envoyée à la source de données afin d’être exécutée.

6. Après l'exécution, les résultats sont envoyés à la passerelle VNet et le service PP VNet 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 de principaux de service. Stockez toutes les informations d'identification du principal de service utilisées pour le chiffrement ou l'accès à Power BI dans un coffre de clés, attribuez des stratégies d'accès appropriées au coffre et révisez régulièrement les autorisations d'accès.

Voir Automatiser les tâches de l'espace de travail et du modèle sémantique Premium avec les principaux de service pour plus de détails.

Microsoft Purview pour Power BI

Protection des informations Microsoft Purview

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

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

• Les données sensibles, à la fois dans le service Power BI et dans Power BI Desktop, peuvent être classées et étiquetées à l'aide des mêmes étiquettes de sensibilité utilisées dans Office et dans Azure.
• Les stratégies de gouvernance peuvent être appliquées lorsque le contenu Power BI est exporté vers des fichiers Excel, PowerPoint, PDF, Word ou .pbix, pour garantir que les données sont protégées même lorsqu'elles quittent Power BI.
• Il est facile de classer et de protéger les fichiers .pbix dans Power BI Desktop, comme c'est le cas dans les applications Excel, Word et PowerPoint. Les fichiers peuvent être facilement étiquetés en fonction de leur niveau de sensibilité. De plus, ils peuvent être chiffrés s'ils contiennent des données commerciales confidentielles, garantissant que seuls les utilisateurs autorisés peuvent modifier ces fichiers.
• Les classeurs Excel héritent automatiquement des étiquettes de sensibilité lorsqu'ils se connectent à Power BI (préversion), ce qui permet de maintenir une classification de bout en bout et d'appliquer une protection lorsque les modèles sémantiques Power BI sont analysés dans Excel.
• Les étiquettes de sensibilité appliquées aux rapports et tableaux de bord Power BI sont visibles dans les applications mobiles Power BI iOS et Android.
• Les étiquettes de sensibilité persistent lorsqu'un rapport Power BI est intégré dans Teams, SharePoint ou un site Web sécurisé. Cela aide les organisations à maintenir la classification et la protection lors de l'exportation lors de l'intégration 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 les étiquettes appliquées aux modèles sémantiques ou aux datamarts dans le service Power BI seront appliquées au nouveau contenu créé par-dessus ces modèles sémantiques et ces datamarts.
• Les API d'analyse d'administration Power BI peuvent extraire l'étiquette de sensibilité d'un élément Power BI, permettant aux administrateurs Power BI et InfoSec de surveiller l'étiquetage dans le service Power BI et de produire des rapports exécutifs.
• Les API d'administration Power BI permettent aux équipes centrales d'appliquer par programmation des étiquettes de confidentialité au contenu du service Power BI.
• Les équipes centrales peuvent créer des stratégies d'étiquetage obligatoires pour imposer l'application d'é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 le contenu Power BI nouveau ou modifié.
• L'étiquetage automatique de la sensibilité en aval dans le service Power BI garantit que lorsqu'une étiquette sur un modèle sémantique ou un magasin de données est appliquée ou modifiée, l'étiquette sera automatiquement appliquée ou modifiée sur tout le contenu en aval connecté au modèle sémantique ou au magasin de données.

Pour plus d'informations, voir Étiquettes de confidentialité dans Power BI.

Stratégies Microsoft Purview Data Loss Prevention (DLP) pour Power BI (préversion)

Les politiques DLP de Microsoft Purview peuvent aider les organisations à réduire le risque de fuite de données commerciales sensibles de Power BI. Les politiques DLP peuvent les aider à respecter les exigences de conformité des réglementations gouvernementales ou sectorielles, 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.

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

• Tous les modèles sémantiques dans les espaces de travail spécifiés dans la politique sont évalués par cette dernière.
• Vous pouvez détecter quand des données sensibles sont télé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 repose sur l'analyse du contenu Microsoft Purview.
• Lorsque vous rencontrez un modèle sémantique identifié comme sensible, vous pouvez voir un conseil de stratégie personnalisé qui vous aide à comprendre ce que vous devez faire.
• Si vous êtes propriétaire d'un modèle sémantique, vous pouvez remplacer une politique et empêcher que votre modèle sémantique soit identifié comme "sensible" si vous avez une raison valable de le faire.
• Si vous êtes propriétaire d'un modèle sémantique, vous pouvez signaler un problème avec une stratégie si vous concluez qu'un type d'informations sensibles a été identifié à tort.
• Des atténuations automatiques des risques, telles que des alertes à l'administrateur de la sécurité, peuvent être invoquées.

Pour plus d'informations, voir Stratégies de prévention des pertes de données pour Power BI.

Microsoft Defender pour les applications cloud pour Power BI

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

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

• Définissez des contrôles en temps réel pour appliquer les sessions utilisateur à risque dans Power BI. Par exemple, si un utilisateur se connecte à Power BI depuis l'extérieur de son pays ou de sa région, la session peut être surveillée par les contrôles en temps réel de Microsoft Defender pour les Apps cloud et des actions risquées, telles que le téléchargement de données marquées avec une sensibilité "hautement confidentielle". étiquette, peut être bloqué immédiatement.
• Examinez l'activité des utilisateurs de Power BI avec le journal d'activité de Microsoft Defender pour les Apps cloud. Le journal d'activité de Microsoft Defender pour les Apps cloud inclut l'activité Power BI telle qu'elle est capturée dans le journal d'audit d'Office 365, qui contient des informations sur toutes les activités des utilisateurs et des administrateurs, ainsi que des informations sur les étiquettes de confidentialité pour les activités pertinentes telles que l'application, la modification et la suppression d'étiquettes. Les administrateurs peuvent tirer parti des filtres avancés et des actions rapides de Microsoft Defender pour les Apps cloud pour une enquête efficace sur les problèmes.
• Créez des stratégies personnalisées pour alerter sur les activités suspectes des utilisateurs dans Power BI. La fonctionnalité de politique d'activité de Microsoft Defender pour les Apps cloud peut être exploitée pour définir vos propres règles personnalisées, pour vous aider à détecter le comportement des utilisateurs qui s'écarte de la norme, et même éventuellement agir en conséquence automatiquement, s'il semble trop dangereux.
• Travaillez avec la détection d'anomalies intégrée de Microsoft Defender pour les Apps cloud. Les politiques de détection des anomalies de Microsoft Defender pour les applications cloud fournissent des analyses comportementales des utilisateurs et un apprentissage automatique prêts à l'emploi afin que vous soyez prêt dès le départ à exécuter une détection avancée des menaces dans votre environnement cloud. Lorsqu'une politique de détection d'anomalies identifie un comportement suspect, elle déclenche une alerte de sécurité.
• Rôle d'administrateur Power BI dans le portail Microsoft Defender for Cloud Apps. Microsoft 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 pour Power BI dans le portail, telles que les alertes, les utilisateurs à risque, les journaux d'activité et d'autres Informations liées à la BI.

Voir Utilisation de Microsoft Defender pour les contrôles Cloud Apps dans Power BI pour plus de détails.

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

Cette section répertorie les fonctionnalités dont la sortie est prévue jusqu'en mars 2021. Étant donné que cette rubrique répertorie les fonctionnalités qui n'ont peut-être pas encore été publiées, les délais de livraison peuvent changer et les fonctionnalités prévues peuvent être publiées après mars 2021, voire ne pas être publiées du tout. Pour plus d'informations sur les aperçus, veuillez consulter les Conditions des Services en Ligne.

Apportez votre propre Analytics de journaux (BYOLA)

Bring Your Own Log Analytics permet l'intégration entre Power BI et Azure Log Analytics. Cette intégration inclut le moteur d'analyse avancé d'Azure Log Analytics, un langage de requête interactif et des constructions d'apprentissage automatique intégrées.

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

Voici quelques questions et réponses courantes relatives à la sécurité dans Power BI. Ceux-ci 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 aux sources de données pour chaque utilisateur pour les informations d'identification cloud ou pour la connectivité via une passerelle personnelle. Les sources de données gérées par une passerelle de données locale peuvent être partagées dans l’entreprise et les autorisations pour ces sources de données peuvent être gérées par l’administrateur de la passerelle. Lors de la configuration d’un modèle sémantique, l’utilisateur est autorisé à sélectionner des informations d’identification à partir de son magasin personnel ou à utiliser une passerelle de données locale pour utiliser des informations d’identification partagées.

  Dans le cas 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 modèle sémantique publié sur le service Power BI, Power BI utilise toujours les informations d'identification de cet utilisateur pour importer des données. Une fois les données importées, l'affichage des données dans les rapports et le tableau de bord n'accède pas à la source de données sous-jacente. Power BI prend en charge l'authentification unique pour les sources de données sélectionnées. Si la connexion est configurée pour utiliser l'authentification unique, les informations d'identification du propriétaire du modèle sémantique sont utilisées pour se connecter à la source de données.

  Pour les rapports connectés à DirectQuery, la source de données est connectée directement à l'aide d'informations d'identification préconfigurées, les informations d'identification préconfigurées sont utilisées pour se connecter à la source de données lorsqu'un utilisateur affiche les données. Si une source de données est connectée directement à l'aide de l'authentification unique, les informations d'identification de l'utilisateur actuel sont utilisées pour se connecter à la source de données lorsque l'utilisateur affiche les données. Lors de l'utilisation 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, ce qui permet aux utilisateurs d'afficher les données auxquelles ils ont des privilèges d'accès. Lorsque la connexion est établie avec des sources de données dans le cloud, l’authentification Microsoft Entra est utilisée pour l’authentification unique ; pour des sources de données locales, Kerberos, Security Assertion Markup Language (SAML) et Microsoft Entra ID sont pris en charge.

  Lors de la connexion avec Kerberos, l'UPN de l'utilisateur est transmis à la passerelle et, à l'aide de la délégation contrainte Kerberos, l'utilisateur est représenté et connecté aux sources de données respectives. SAML est également pris en charge sur la source de données Gateway for SAP HANA. Plus d'informations sont disponibles dans l'aperçu de l'authentification unique pour les passerelles.

  Si la source de données est Azure Analysis Services ou Analysis Services sur site et que la sécurité au niveau de la ligne (RLS) et/ou la sécurité au niveau de l'objet (OLS) est configurée, le service Power BI appliquera cette sécurité au niveau de la ligne, et les utilisateurs qui ne le font pas. t disposer de 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 verra pas les données pour lesquelles l'utilisateur ne dispose pas de privilèges suffisants.

  La sécurité au niveau de la ligne avec Power BI peut être utilisée pour restreindre l'accès aux données pour des utilisateurs donnés. Les filtres limitent l'accès aux données au niveau de la ligne et vous pouvez définir des filtres au sein du rôle.

  La sécurité au niveau de l'objet (OLS) peut être utilisée pour sécuriser des tables ou des colonnes sensibles. Cependant, contrairement à la sécurité au niveau des lignes, la sécurité au niveau des objets 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 tels 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. De plus, les utilisateurs sans autorisation 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 les colonnes sécurisées n'existent tout simplement pas.

  La sécurité au niveau des objets, associée à la sécurité au niveau des lignes, permet d'améliorer la sécurité de niveau entreprise sur les rapports et les modèles sémantiques, garantissant que seuls les utilisateurs disposant des autorisations requises ont accès pour afficher et interagir 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 de 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 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 ?

• Lors de l'accès à une source de données, le service Power BI suit le processus décrit dans la section Authentification aux sources de données plus haut dans ce document.

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 non activées pour la sécurité au niveau du rôle (RLS), si un tableau de bord, un rapport ou un modèle de données est partagé avec d'autres utilisateurs via Power BI, les données sont alors disponibles pour les utilisateurs avec lesquels elles sont partagées afin d'afficher et d'interagir avec. Power BI ne réauthentifie pas les utilisateurs par rapport à la source d'origine des données ; une fois les données téléchargées dans Power BI, l'utilisateur qui s'est authentifié par rapport aux données source est responsable de la gestion des autres utilisateurs et groupes qui peuvent afficher les données.

  Lorsque des connexions de données sont établies avec une source de données compatible RLS, telle qu'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 modèle sémantique 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 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 sur le lien suivant : Ports passerelles

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 sur 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 incluent les téléchargements de produits (tels que Power BI Desktop, la passerelle de données sur site ou les applications Power BI de divers fournisseurs de services indépendants), les fichiers de configuration du navigateur utilisés pour initier et établir toute connexion ultérieure avec le service Power BI, ainsi que comme page de connexion sécurisée initiale à 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 alors le jeton Microsoft Entra, les informations de session, l’emplacement du cluster back-end associé et la collection de fichiers téléchargés à partir du cluster Azure CDN et WFE pendant toute la durée de la session du navigateur du service Power BI.

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

• Nombre Il incombe au client d’examiner le code de visuel personnalisé et de déterminer s’il est fiable. Tout le code visuel personnalisé est exploité dans un environnement sandbox, de sorte 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 ?

• Nombre L'éditeur de l'application est responsable du contenu, tandis qu'il incombe au client d'examiner et de déterminer s'il doit faire confiance à l'éditeur de l'application modèle.

Existe-t-il des modèles d'applications capables d'envoyer des informations en dehors du réseau client ?

• Oui. Il incombe au client de consulter la politique de confidentialité de l'éditeur et de déterminer s'il convient d'installer l'application modèle sur le client. L'éditeur est chargé d'informer le client sur le comportement et les fonctionnalités de l'application.

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

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

  Alternativement, les clients peuvent également configurer un locataire dans une région spécifique. Cependant, ces locataires n'ont pas d'ayant droit de données distinct de Microsoft. La tarification des clouds nationaux/régionaux est différente de celle du service Power BI commercial généralement disponible. Pour plus d'informations sur la disponibilité du service Power BI pour les clouds nationaux/régionaux, voir Clouds nationaux/régionaux 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 des clients ayant un abonnement Power BI Premium implémentent un processus d’autorisation Business-to-Business (B2B) Microsoft Entra en utilisant Microsoft Entra ID 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 Microsoft Entra.

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

• L'authentification côté service de la séquence d'authentification de l'utilisateur se produit comme décrit dans les étapes suivantes, qui sont illustrées dans l'image qui les suit.

1. Un utilisateur initie une connexion au service Power BI à partir d'un navigateur, soit en tapant l'adresse Power BI dans la barre d'adresse, soit en sélectionnant Se connecter à partir de la page marketing Power BI (https://powerbi.microsoft.com). La connexion est établie à l’aide de TLS 1.2 et HTTPS, et toutes les communications 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 du service Power BI le plus proche précédemment déterminé avec un code d'authentification.

5. Le cluster WFE communique avec Microsoft Entra ID pour obtenir un jeton de sécurité Microsoft Entra en tirant parti du code d’authentification. Lorsque Microsoft Entra ID renvoie l’authentification réussie de l’utilisateur et retourne un jeton de sécurité Microsoft Entra, le cluster WFE consulte le service global Power BI qui gère une liste de tenants et leur emplacement de cluster back-end Power BI et détermine quel back-end Power BI le cluster de service contient le tenant de l’utilisateur. Le cluster WFE renvoie ensuite une page d'application au navigateur de l'utilisateur avec les informations de session, d'accès et de routage nécessaires à son fonctionnement.

6. Désormais, lorsque le navigateur du client requiert des données client, il envoie des requêtes à l’adresse du cluster back-end incluant le jeton d’accès Microsoft Entra dans l’en-tête d’autorisation. Le cluster back-end Power BI lit le jeton d’accès Microsoft Entra et valide la signature pour confirmer la validité de l’identité de la requête. Le jeton d’accès Microsoft Entra aura une date d’expiration définie conformément aux stratégies Microsoft Entra et, pour maintenir la session active, le client Power BI dans le navigateur de l’utilisateur effectuera des demandes périodiques de renouvellement du jeton d’accès avant son expiration.

Ressources supplémentaires

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

• Prise en main de Power BI Desktop
• API REST Power BI - Vue d’ensemble
• Informations de référence sur l’API de Power BI
• Passerelle de données locale
• Clouds nationaux/régionaux Power BI
• Power BI Premium
• Vue d’ensemble de l’authentification unique (SSO) pour les passerelles dans Power BI