Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Power BI Embedded a plusieurs façons de filtrer les données et de restreindre l’accès aux données à des utilisateurs spécifiques. Voici quelques-unes de ces méthodes de sécurité :
Sécurité au niveau de la ligne (RLS) RLS vous permet de contrôler l’accès aux lignes d’une table de base de données via des appartenances à des groupes. Lorsque vous incorporez des éléments, vous pouvez utiliser RLS pour restreindre l’accès utilisateur à des lignes de données spécifiques. Avec RLS, différents utilisateurs peuvent travailler avec les mêmes éléments, mais voir des données différentes.
Sécurité au niveau de l’objet (OLS) OLS vous permet de masquer des tables ou des colonnes spécifiques des visionneuses de rapports. Vous pouvez également sécuriser les noms d’objets sensibles et les métadonnées pour les empêcher d’être découverts.
Isolation basée sur l’espace de travail et mutualisation
Dans ce scénario, chaque client a son propre modèle sémantique distinct. Étant donné que chaque client n’a accès qu’à son propre espace de travail, aucun filtrage supplémentaire n’est nécessaire, bien que cette méthode puisse être combinée avec RLS pour filtrer davantage les données au sein de chaque organisation.
Solutions de sécurité pour différents scénarios ISV
Selon la situation, certains cas courants où les mesures de sécurité peuvent être appliquées sont les suivantes :
Les ISVs de petite à moyenne taille qui servent plusieurs clients et souhaitent que chaque client voie uniquement ses propres données. Si la base de clients n’est pas trop volumineuse, l’éditeur de logiciels indépendants peut utiliser un modèle sémantique unique et un rapport pour tous ses clients, et utiliser des lignes de sécurité dynamiques pour filtrer les données pour chaque client.
Les éditeurs de logiciels indépendants qui servent un ou plusieurs grands clients ou organisations composées de plusieurs services. Les ISV peuvent séparer leurs clients avec une combinaison de RLS statique et dynamique, et éventuellement OLS.
Les éditeurs de logiciels indépendants à grande échelle, avec des milliers de clients, doivent permettre à chaque client de voir uniquement ses propres données. L’éditeur de logiciels indépendants peut utiliser l’isolation basée sur l’espace de travail avec des profils de principal de service. Chaque client peut obtenir son propre rapport et son modèle sémantique, et le fournisseur de logiciels indépendant peut filtrer davantage au sein de chaque organisation en utilisant RLS.
Incorporer un rapport qui utilise des fonctionnalités de sécurité
Selon votre configuration, vous devrez peut-être effectuer plusieurs étapes avant de pouvoir générer un jeton incorporé. Pour obtenir des instructions sur l’incorporation de rapports ou d’autres éléments, accédez au lien qui décrit le mieux votre scénario spécifique :
- Standard RLS
- Incorporation de rapports paginés
- SQL Server Analysis Services
- Azure Analysis Services
- Sécurité au niveau objet
Considérations et limitations
- L’attribution d’utilisateurs à des rôles au sein du service Power BI n’affecte pas la sécurité réseau ou OLS lors de l’utilisation d’un jeton incorporé (l’application possède uniquement le scénario de données ).
- Bien que les paramètres RLS ne s’appliquent pas aux administrateurs, aux membres ou aux contributeurs, lorsque vous fournissez une identité avec un jeton incorporé, les autorisations RLS de cette identité seront appliquées aux données.
Contenu connexe
Plus de questions ? Essayez d’interroger la communauté Power BI