Sécurité dans Power BI

Pour plus d’informations sur la sécurité dans Power BI, consultez le livre blanc Sécurité dans Power BI.

Pour planifier la sécurité dans Power BI, consultez la série d’articles sur la sécurité de la planification de l’implémentation de Power BI. Elle développe le contenu du livre blanc Sécurité dans Power BI. Bien que le livre blanc Sécurité dans Power BI se concentre sur des sujets techniques clés tels que l’authentification, la résidence des données et l’isolement réseau, l’objectif principal de la série est de vous fournir des considérations et décisions pour vous aider à planifier la sécurité et la confidentialité.

Le service Power BI repose sur Azure, plateforme et infrastructure de cloud computing de Microsoft. L’architecture du service Power BI est basée sur deux clusters :

• Le cluster web front-end (WFE). Le cluster WFE gère la connexion initiale et l’authentification au service Power BI.
• Le cluster principal. Une fois authentifié, le cluster principal gère toutes les interactions d’utilisateur suivantes. Power BI utilise Microsoft Entra ID pour stocker et gérer les identités utilisateur. Microsoft Entra ID gère également le stockage des données et les métadonnées à l’aide respectivement du Stockage Blob Azure et d’Azure SQL Database.

Architecture de Power BI

Le cluster WFE utilise Microsoft Entra ID pour authentifier les clients et fournir des jetons pour les connexions client suivantes au service Power BI. Power BI utilise Azure Traffic Manager (Traffic Manager) pour diriger le trafic utilisateur vers le centre de données le plus proche. Traffic Manager dirige les requêtes à l’aide de l’enregistrement DNS du client qui tente de se connecter, de s’authentifier et de télécharger du contenu et des fichiers statiques. 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.

Le cluster principal détermine comment les clients authentifiés interagissent avec le service Power BI. Le cluster principal gère les visualisations, les tableaux de bord utilisateur, les modèles sémantiques, les rapports, le stockage de données, les connexions de données, l’actualisation des données et d’autres aspects de l’interaction avec le service Power BI. Le rôle Passerelle sert de passerelle entre les demandes des utilisateurs et le service Power BI. Les utilisateurs n’interagissent directement avec aucun rôle autre que le rôle Passerelle. Le rôle Gestion des API Azure gère au final le rôle Passerelle.

Important

Le rôles Gestion des API Azure et Passerelle sont accessibles via l’Internet public. Ils fournissent entre autres des fonctionnalités d’authentification, d’autorisation, de protection DDoS, de limitation, d’équilibrage de charge et de routage.

Sécurité du stockage des données

Power BI utilise deux référentiels principaux pour le stockage et la gestion des données :

• Les données chargées à partir d’utilisateurs sont généralement envoyées au Stockage Blob Azure.
• Toutes les métadonnées, y compris les éléments du système lui-même, sont stockées dans Azure SQL Database.

La ligne en pointillés affichée dans le diagramme du cluster principal clarifie la limite entre les deux composants accessibles par les utilisateurs affichés à gauche de la ligne en pointillés. Les rôles accessibles uniquement par le système s’affichent à droite. Quand un utilisateur authentifié se connecte au service Power BI, la connexion et toute requête du client sont acceptées et gérées par le rôle Passerelle qui interagit ensuite pour le compte de l’utilisateur avec le reste du service Power BI. Par exemple, quand un client tente d’afficher un tableau de bord, le rôle Passerelle accepte cette demande, puis envoie séparément une demande au rôle Présentation pour récupérer les données nécessaires au navigateur pour afficher le tableau de bord. Finalement, les connexions et les requêtes clients sont gérées par la rôle Gestion des API Azure.

Authentification des utilisateurs

Power BI utilise Microsoft Entra ID pour authentifier les utilisateurs qui se connectent au service Power BI. Des informations d’identification de connexion sont requises chaque fois qu’un utilisateur tente d’accéder à des ressources sécurisées. Les utilisateurs se connectent au service Power BI à l’aide de l’adresse e-mail avec laquelle ils ont établi leur compte Power BI. Power BI utilise les mêmes informations d’identification que le nom d’utilisateur effectif et les transmet aux ressources chaque fois qu’un utilisateur tente de se connecter aux données. Le nom d’utilisateur effectif est ensuite mappé à un nom d’utilisateur principal (UPN) et mis en correspondance avec le compte de domaine Windows associé, auquel l’authentification est appliquée.

Pour les organisations qui ont utilisé des adresses e-mail professionnelles pour la connexion à Power BI, par exemple david@contoso.com, le mappage entre le nom d’utilisateur effectif et l’UPN est simple. Pour les organisations qui n’ont pas utilisé d’adresses e-mail professionnelles, par exemple david@contoso.onmicrosoft.com, le mappage entre Microsoft Entra ID et les informations d’identification locales nécessite que la synchronisation d’annuaires fonctionne correctement.

La sécurité de plateforme pour Power BI inclut également la sécurité d’environnement d’architecture mutualisée, la sécurité réseau et la possibilité d’ajouter d’autres mesures de sécurité basées sur Microsoft Entra ID.

Sécurité des données et des services

Pour plus d’informations, consultez Centre de gestion de la confidentialité Microsoft, produits et services qui reposent sur la confiance.

Comme décrit précédemment, les serveurs AD locaux utilisent une connexion Power BI pour mapper à un UPN pour les informations d’identification. Toutefois, les utilisateurs doivent comprendre la sensibilité des données qu’ils partagent. Une fois que vous vous êtes connecté(e) en toute sécurité à une source de données, puis partagez des rapports, des tableaux de bord ou des modèles sémantiques avec d’autres personnes, les destinataires se voient octroyer l’accès au rapport. Les destinataires n’ont pas besoin de se connecter à la source de données.

Une exception est la connexion à SQL Server Analysis Services à l’aide de la Passerelle de données locale. Les tableaux de bord sont mis en cache dans Power BI, mais l’accès aux rapports ou modèles sémantiques sous-jacents lance l’authentification pour chaque utilisateur qui tente d’accéder au rapport ou au modèle sémantique. L’accès n’est accordé que si l’utilisateur dispose d’informations d’identification suffisantes pour accéder aux données. Pour plus d’informations, consultez Informations approfondies sur la passerelle de données locale.

Mise en œuvre de l’utilisation de la version TLS

Les administrateurs informatiques et réseau peuvent appliquer l’impératif d’utiliser la version TLS (Transport Layer Security) actuelle pour toutes les communications sécurisées sur leur réseau. Windows fournit le support pour les versions TLS sur le Microsoft Schannel Provider. Pour plus d’informations, consultez Protocoles dans TLS/SSL (SSP Schannel) .

Cette implémentation est accomplie en définissant des clés de Registre au niveau administratif. Pour plus d’informations sur l’implémentation, consultez Gestion des protocoles SSL/TLS et des suites de chiffrement pour AD FS.

Power BI Desktop nécessite TLS (Transport Layer Security) version 1.2 (ou ultérieure) pour sécuriser vos points de terminaison. Les navigateurs Web et les autres applications clientes qui utilisent des versions TLS antérieures à TLS 1.2 ne pourront pas se connecter. Si des versions TLS plus récentes sont requises, Power BI Desktop respecte les paramètres de clé de Registre décrits dans ces articles, et crée uniquement des connexions répondant à l’exigence de version TLS autorisée dans ces paramètres du Registre, le cas échéant.

Pour plus d’informations sur la définition de ces clés de Registre, consultez Paramètres de Registre TLS (Transport Layer Security).