Aide de Tableau Server sur Linux

Si votre entreprise a déjà déployé des efforts pour mettre en place un système de sécurité au niveau des lignes (RLS, pour Row-Level Security) dans une base de données, vous pouvez utiliser l’une des techniques suivantes pour tirer parti de votre RLS existant. Pour pouvoir exploiter les modèles de sécurité de la base de données, des connexions en direct sont nécessaires. De plus, ces techniques ne sont probablement pas disponibles dans Tableau Cloud. Le nom d’utilisateur Tableau pour Tableau Cloud est une adresse e-mail unique qui n’est généralement pas l’identité de l’utilisateur côté base de données.

Il n’est pas nécessairement plus facile ou préférable de mettre en œuvre un modèle RLS intégré plutôt que de le construire spécifiquement pour Tableau. Ces techniques sont généralement mises à profit lorsqu’une entreprise a déjà investi dans ces technologies et qu’elle veut tirer parti de l’investissement.

Remarque : pour plus d’informations sur les alternatives que vous pouvez utiliser pour implémenter la sécurité au niveau des lignes dans Tableau, consultez Présentation des options de sécurité au niveau des lignes dans Tableau.

Emprunt d’identité (Microsoft SQL Server)

Microsoft SQL Server (et quelques systèmes connexes) peut être configuré de sorte que les utilisateurs de la base de données n’aient accès qu’aux vues avec des filtres RLS intégrés, en utilisant des tables de jonction de sécurité ou des vues créées par le DBA. Tableau peut en tirer profit en utilisant un concept appelé « emprunt d’identité ».

Lors de la publication d’une source de données Tableau contenant une connexion MS SQL Server à Tableau Server, deux options d’authentification sont disponibles pour profiter de l’emprunt d’identité. Le menu qui s’affiche varie selon que vous êtes connecté à SQL Server en utilisant l’authentification réseau ou en entrant un nom d’utilisateur/mot de passe.

Pour activer le filtrage RLS pour tout utilisateur autorisé à accéder à la source de données publiée dans Tableau Server, le compte AD Run-As ou les informations d’identification intégrées SQL Server doivent disposer de l’autorisation EXECUTE AS pour tous les utilisateurs Tableau de la base de données qui auront accès au tableau de bord ou à la source de données. Tous les utilisateurs Tableau doivent exister dans le serveur de base de données en tant qu’utilisateurs, avec les droits SELECT pour les vues auxquelles vous essayez de vous connecter (et auxquelles RLS est appliqué). Voir Exigences de simulation pour la liste complète des exigences.

Kerberos et délégation contrainte

La délégation contrainte au sein de Tableau Server à l’aide de Kerberos fonctionne de la même manière que l’emprunt d’identité en ce sens qu’elle permet à Tableau Server d’utiliser les identifiants Kerberos de la vue d’un classeur ou d’une vue pour exécuter une requête au nom du Viewer. Ainsi, si RLS est configuré sur la base de données, l’utilisateur Viewer du classeur ne verra que ses données.

Pour voir la liste complète des base de données où la délégation Kerberos est prise en charge, consultez Activer la délégation Kerberos. Active Directory est requis. L’ordinateur sur lequel Tableau Server est installé doit être lié au domaine Active Directory. La méthode d’authentification(Le lien s’ouvre dans une nouvelle fenêtre) spécifiée lors de la publication de la source de données doit être Informations d’identification du Viewer.

Notez que Kerberos peut être utilisé pour RLS lorsque vous utilisez Microsoft Analysis Services.

Cubes OLAP

Les connexions de type cube OLAP dans Tableau n’ont pas l’équivalent d’un filtre de source de données, ce qui est requis pour la méthode RLS basée sur la table des droits dans le Tableau, ou pour accéder à la fonction USERNAME(). Pour ces raisons, Kerberos et la délégation contrainte sont une approche recommandée pour RLS avec des bases de données OLAP. Tableau peut ainsi exploiter le filtrage utilisateur qui a déjà été mis en œuvre du côté du serveur OLAP.

Si les utilisateurs visualisant le tableau de bord ne font pas partie du domaine, il est possible d’appliquer l’approche manuelle de création des filtres utilisateur. Toutefois, étant donné que l’ensemble de filtres utilisateur généré ne peut pas être ajouté en tant que filtre de source de données et qu’il existera plutôt sur l’étagère Filtres, il est important que la fonctionnalité de modification sur le Web et de téléchargement de classeur ne soit autorisée pour aucune vue publiée utilisant cette méthode.

Délégation SAML et SAP HANA

Si Tableau Server est configuré pour utiliser Configuration de SSO SAP HANA afin de fournir une expérience d’authentification unique, les informations d’identification du Viewer sont utilisées pour exécuter la requête en tant qu’utilisateur, laquelle s’exécutera avec la sécurité appliquée au niveau utilisateur. La méthode d’authentification(Le lien s’ouvre dans une nouvelle fenêtre) spécifiée lors de la publication de la source de données doit être Informations d’identification du Viewer.

SQL initial pour forcer une session spécifique à l’utilisateur (Oracle VPD)

Avec SQL initial, vous pouvez spécifier une commande SQL qui est exécutée lorsque la connexion à la base de données a pour objectif de configurer les tables temporaires à utiliser pendant la session ou de configurer un environnement de données personnalisé.

Pour Oracle VPD, vous pouvez configurer une session spécifique à un utilisateur en exécutant une procédure stockée ou une fonction particulière afin de définir le contexte de la connexion à la base de données en fonction du nom d’utilisateur de l’utilisateur Tableau :

begin
DBMS_SESSION.SET_IDENTIFIER([TableauServerUser]);
end;

Les exigences de haut niveau qui s’appliquent à l’utilisation de RLS sont les mêmes que pour l’emprunt d’identité. Le DBA doit configurer le VPD et tous les utilisateurs associés pour exister dans la base de données.

Sur MS SQL Server, vous pouvez forcer l’exécution d’une commande EXECUTE (cependant, ceci est similaire à ce que Tableau fait déjà avec l’emprunt d’identité) :

EXECUTE AS USER = [TableauServerUser] WITH NO REVERT;

Remarque : si la source de données est intégrée et qu’un utilisateur possède le droit de modification sur le Web ou de téléchargement du classeur, alors le RLS est inexistant puisque SQL initial qui l’applique peut facilement être supprimé. La source de données doit être publiée séparément au lieu de rester intégrée au classeur.

Matrice de comparaison pour les méthodes de sécurité au niveau des lignes