Restreindre l’accès aux objets de modèle Power BI
En tant que modeleur de données, vous pouvez envisager de restreindre l’accès utilisateur aux objets de modèle Power BI. Une sécurité au niveau de l’objet (OLS) peut restreindre l’accès à des tables et colonnes spécifiques, ainsi qu’à leurs métadonnées. En règle générale, vous appliquez OLS pour sécuriser des objets qui stockent des données sensibles, comme les données personnelles des employés.
Quand Power BI applique OLS, non seulement il restreint l’accès aux tables et aux colonnes, mais il peut également sécuriser des métadonnées. Lorsque vous sécurisez des métadonnées, il n’est pas possible de récupérer d’informations sur les tables et colonnes sécurisées à l’aide de Vues de gestion dynamique (DMV).
Important
Des modèles tabulaires peuvent masquer des tables et des colonnes (et d’autres objets) à l’aide d’une perspective. Une perspective définit des sous-ensembles visibles d’objets de modèle pour vous aider à fournir un focus spécifique pour des auteurs de rapports. Les perspectives sont destinées à réduire la complexité d’un modèle, ce qui aide les auteurs de rapports à trouver des ressources intéressantes. Toutefois, les perspectives ne sont pas une fonctionnalité de sécurité, car elles ne sécurisent pas les objets. Un utilisateur peut toujours interroger une table ou une colonne même si elles ne pas visibles de lui.
Considérons un exemple chez Adventure Works. Cette organisation dispose d’une table de dimensions d’entrepôt de données nommée DimEmployee. La table inclut des colonnes qui stockent le nom, le téléphone, l’adresse e-mail et le salaire de l’employé. Bien que les consommateurs de rapports généraux puissent voir le nom et les coordonnées des employés, ils ne doivent pas être en mesure de voir les valeurs de salaires. Seul le personnel senior des ressources humaines est autorisé à voir les valeurs de salaires. Par conséquent, le modeleur de données a utilisé OLS pour accorder l’accès à la colonne des salaires uniquement à du personnel spécifique des ressources humaines.
OLS est une fonctionnalité héritée d’Azure Analysis Services (AAS) et de SQL Server Analysis Services (SSAS). La fonctionnalité est disponible dans Power BI Premium pour assurer la compatibilité descendante des modèles migrés vers Power BI. Pour cette raison, il n’est pas possible de configurer complètement OLS dans Power BI Desktop.
Configurer OLS
Pour configurer OLS, vous commencez par créer des rôles. Vous pouvez créer des rôles dans Power BI Desktop de la même façon que lors de la configuration de RLS. Ensuite, vous devez ajouter des règles OLS aux rôles. Cette fonctionnalité n’étant pas prise en charge par Power BI Desktop, vous devez adopter une approche différente.
Vous ajoutez des règles OLS à un modèle Power BI Desktop à l’aide d’un point de terminaison XML for Analysis (XMLA). Les points de terminaison XMLA sont disponibles avec Power BI Premium, et fournissent l’accès au moteur Analysis Services dans le service Power BI. Le point de terminaison en lecture/écriture prend en charge la gestion du jeu de données, la gestion du cycle de vie des applications, la modélisation avancée des données, etc. Vous pouvez utiliser des API avec point de terminaison XMLA pour les scripts, tels que Tabular Model Scripting Language (TMSL) ou le module PowerShell SqlServer. Vous pouvez également utiliser un outil client, comme SSMS. Il existe également des options d’outils tiers, comme l’éditeur tabulaire qui est un outil open source pour créer, maintenir et gérer des modèles.
Par défaut, toutes les tables et colonnes de modèle ne sont pas limitées. Vous pouvez les définir sur None ou Read. Quand elles sont définies sur None, les utilisateurs associés au rôle ne peuvent pas accéder à l’objet. Quand elles sont définies sur Read, les utilisateurs associés au rôle peuvent accéder à l’objet. Lorsque vous limitez des colonnes spécifiques, vérifiez que la table n’est pas définie sur None.
Une fois que vous avez ajouté les règles OLS, vous pouvez publier le modèle sur le service Power BI. Utilisez le même processus pour RLS afin de mapper des comptes et des groupes de sécurité aux rôles.
Considérations
Dans un rapport Power BI, quand un utilisateur n’a pas l’autorisation d’accéder à une table ou une colonne, il reçoit un message d’erreur. Le message les informera que l’objet n’existe pas.
Considérez soigneusement si OLS est la bonne solution pour votre projet. Quand un utilisateur ouvre un rapport Power BI qui interroge un objet restreint (pour eux), le message d’erreur pourrait être déroutant et entraînera une expérience négative. Le rapport lui semble corrompu. Une meilleure approche pourrait être de créer un ensemble distinct de modèles ou de rapports pour les différentes exigences du consommateur de rapports.
Restrictions
Il existe quelques restrictions à connaître lors de l’implémentation d’OLS.
Vous ne pouvez pas combiner RLS et OLS dans le même rôle. Si vous devez appliquer RLS et OLS dans le même modèle, créez des rôles distincts dédiés à chaque type. Vous ne pouvez pas non plus définir de sécurité au niveau de la table si elle interrompt une chaîne de relation. Par exemple, s’il existe des relations entre les tables A et B, et B et C, vous ne pouvez pas sécuriser la table B. Si la table B est sécurisée, une requête sur la table A ne peut pas transiter les relations entre les tables A et B, et B et C. Dans ce cas, vous pourriez configurer une relation distincte entre les tables A et C.
Cependant, les relations de modèle qui font référence à une colonne sécurisée fonctionneront, à condition que la table de la colonne ne soit pas sécurisée.
Enfin, s’il n’est pas possible de sécuriser des mesures, une mesure qui référence des objets sécurisés est automatiquement restreinte.
Pour plus d’informations, consultez Sécurité au niveau de l’objet.