Restreindre l’accès au niveau des lignes de données
Lorsque vous partagez des classeurs avec d’autres utilisateurs en les publiant sur Tableau Server ou Tableau Cloud, par défaut, tous les utilisateurs qui ont accès aux classeurs peuvent voir toutes les données affichées dans les vues. Vous pouvez remplacer ce comportement en appliquant un type de filtre qui vous permet de spécifier quelles données (lignes) une personne connectée au serveur peut voir dans la vue.
Cette approche de la sécurisation des données au niveau des lignes s’applique aux sources de données avec des connexions en direct et aux sources de données d’extrait dont les tables sont stockées en tant que tables multiples. Pour plus d’informations sur le stockage des données d’extraits à l’aide de tables multiples, consultez Extraire vos données.
Remarque : pour plus d’informations sur les solutions de rechange que vous pouvez utiliser pour mettre en œuvre la sécurité au niveau des lignes dans Tableau, consultez Aperçu des options de sécurité au niveau des lignes dans Tableau(Le lien s’ouvre dans une nouvelle fenêtre) dans l’aide de Tableau Server.
Pour plus d’informations connexes, consultez le document technique Meilleures pratiques pour la sécurité au niveau des lignes avec les tables de droits(Le lien s’ouvre dans une nouvelle fenêtre).
Fonctionnement du filtrage basé sur un utilisateur
Supposons que vous avez créé un rapport de ventes trimestriel pour un ensemble de produits sur plusieurs années, dans différentes régions géographiques.
Lorsque vous publiez ce rapport, vous souhaitez autoriser chaque responsable régional à voir uniquement les données pertinentes pour sa région. Au lieu de créer une vue distincte pour chaque responsable, vous pouvez définir un filtre utilisateur limitant l’accès aux données en fonction des caractéristiques de l’utilisateur, par exemple son rôle.
Ce type de restriction de l’accès aux données est appelé Sécurité au niveau de la ligne (RLS). Tableau propose les approches suivantes de la sécurité au niveau de la ligne :
Créer un filtre utilisateur et associer les utilisateurs à des valeurs manuellement.
Cette méthode est pratique mais nécessite beaucoup de maintenance, et la sécurité peut être hypothétique. Elle doit être effectuée au niveau de chaque classeur, et vous devez mettre à jour le filtre et republier la source de données lorsque votre base d’utilisateurs change.
Créer un filtre dynamique en utilisant un champ de sécurité dans les données.
Cette méthode vous permet de créer un champ calculé qui automatise le processus d’association des utilisateurs à des valeurs de données. Cette méthode exige que les données sous-jacentes incluent les informations de sécurité que vous souhaitez utiliser pour le filtrage.
La manière la plus courante consiste à utiliser une table de référence (« look-up », « entitlements » ou « security ») qui contient ces informations. Par exemple, si vous souhaitez filtrer une vue de manière à ce que seuls les responsables puissent la voir, les données sous-jacentes doivent inclure les noms d’utilisateur et spécifier le rôle de chaque utilisateur.
Le filtrage étant défini au niveau des données et automatisé par le champ calculé, cette méthode est plus sûre que d’associer les utilisateurs à des valeurs de données manuellement.
Ajout de filtres utilisateur à des sources de données
Les deux méthodes de la précédente section décrivent comment ajouter des filtres aux données intégrées dans les classeurs. Si plusieurs classeurs se connectent aux mêmes données, au lieu d’accumuler les filtres sur chaque classeur, vous pouvez filtrer la source de données, puis connecter les classeurs à la source de données après l’avoir publiée.
Les classeurs qui se connectent à votre source de données filtrée exposent uniquement les données que l’utilisateur connecté au serveur est autorisé à voir. En outre, tous les classeurs connectés affichent les actualisations de données à mesure qu’elles ont lieu.
Extraits vs. connexions en direct avec les filtres utilisateur
En général, lorsque vous utilisez l’une des méthodes décrites ci-dessus, RLS avec les extraits est plus rapide à créer et offre de meilleures performances que RLS avec les sources de données utilisant des connexions en direct.
Exigences pour RLS avec des sources de données d’extrait
Comme mentionné précédemment, la première exigence d’utilisation de RLS avec des extraits est que les données de l’extrait soient stockées à l’aide de plusieurs tables physiques. Vous pouvez configurer votre extrait de manière à ce que les données soient stockées à l’aide de plusieurs tables physiques en suivant les instructions de la section Extraire vos données.
Outre les exigences ci-dessus, vous devez prendre en considération plusieurs points supplémentaires si vous comptez utiliser RLS avec votre extrait. Comme les données d’extrait stockées à l’aide de plusieurs tables ne prennent pas en charge les filtres d’extrait et certaines autres fonctionnalités qui aident à réduire la quantité de données dans l’extrait, il est recommandé d’envisager l’une des suggestions suivantes :
Connectez-vous aux données à l’aide de SQL personnalisé
Connectez-vous à une vue de base de données qui affiche déjà le niveau de filtrage approprié
Pour plus d’informations sur ces suggestions, consultez Extraire vos données.
Pratiques recommandées pour RLS avec les sources de données d’extrait
Pour une exécution efficace de RLS avec des extraits, Tableau recommande de conserver le nombre de deux tables (ou vues de base de données ou requêtes SQL personnalisées) dans vos extraits. En d’autres termes, Tableau recommande que les tables dans votre extrait comportent les types de tables suivants :
Une table de données—il s’agit de la table « object » (objet) qui contient toutes les données que vous souhaitez afficher.
Une table de référence—il s’agit de la table « look-up » (recherche) ou « entitlements » (autorisations) qui contient les informations utilisateur et les groupes de sécurité auxquels les utilisateurs appartiennent.
En réduisant à deux le nombre de tables dans votre extrait, vous vous assurez que la seule jointure que Tableau doit effectuer se trouve entre ces deux tables et vous évitez toute duplication des données ou « explosion de jointure ».
À propos de RLS et des versions précédentes de Tableau
Auparavant, Tableau ne pouvait pas prendre en charge les flux de travail RLS avec des extraits en raison des complications liées à la duplication des lignes et aux performances. Au bout du compte, ces complications provenaient de l’extrait dont les données pouvaient uniquement être stockées et interrogées en tant que table unique. Toutefois, depuis Tableau 2018.3, vous pouvez choisir de stocker les données dans votre extrait en utilisant plusieurs tables et donc en activant un flux de travail pour RLS avec des extraits, comme vous le faisiez peut-être précédemment avec des sources de données comportant des connexions en direct.
Pour une discussion complète sur RLS avec des extraits dans Tableau, consultez le blogue publié par un consultant avant-vente de Tableau qui dispose d’une riche expérience dans ce domaine.
Décharge de responsabilité : Le fait de cliquer sur ce lien vous emmènera hors du site Tableau.com. Bien que nous mettions tout en œuvre pour garantir l’exactitude et la pertinence des liens vers des sites Web externes, Tableau ne peut être tenu responsable du contenu externe, ni le prendre en charge.
Voir également
Sécurité des données(Le lien s’ouvre dans une nouvelle fenêtre) dans l’aide de Tableau Server
Aperçu des options de sécurité au niveau des lignes(Le lien s’ouvre dans une nouvelle fenêtre) dans Tableau dans l’aide de Tableau Server