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 Online. Le nom d'utilisateur Tableau pour Online 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

Méthode Utile lorsque Avantages Inconvénients
Table des droits (recommandé)
  • Il existe un concept des droits dans la base de données
  • L'entreprise met en place un système de sécurité au niveau des lignes pour la première fois
  • Facilité de test, de mise à jour, de maintenance et de mise à l'échelle
  • Fonctionne aussi bien pour les connexions en direct que pour les extraits dans la version 2018.3+
  • Nécessite la création et la maintenance d'une table des droits
  • Pourrait nécessiter la sélection et la création de clés appropriées afin d'optimiser les performances
CONTAINS() avec des extraits
  • Implémentation de RLS dans les extraits antérieurs à la version 2018.3
  • Permet de tirer profit de l'efficacité des extraits
  • Nécessite le mappage de tous les utilisateurs dans une seule colonne
  • Difficile de revenir à des connexions en direct en raison du calcul des chaînes
Emprunt d'identité
  • Chaque utilisateur accédant aux données existera en tant qu'utilisateur sur SQL Server (généralement, des déploiements internes)
  • La sécurité est gérée et maintenue en un seul endroit : la base de données
  • Nécessite que chaque personne accédant à la vue existe en tant qu'utilisateur dans SQL Server
  • Fonctionne uniquement pour Microsoft SQL Server
Kerberos
  • Toutes les bases de données nécessaires sont configurées pour la délégation Kerberos et RLS est configuré sur la base de données (généralement des déploiements internes)
  • Le nom du Viewer apparaît dans les journaux d'accès de la base de données
  • La gestion et la maintenance de la sécurité s'effectuent dans la base de données
  • Tableau doit être configuré pour utiliser LDAP - Active Directory
  • Tableau Server doit être lié au domaine AD
  • Chaque utilisateur doit exister dans votre domaine AD
SQL initial
  • La base de données prend en charge SQL initial et RLS est configuré du côté de la base de données
  • Permet la transmission des paramètres Tableau au moment du chargement
  • Connexion dédiée qui ne peut pas être partagée avec d'autres utilisateurs
  • Les utilisateurs doivent exister dans la base de données pour exécuter une requête en tant qu'utilisateur
  • Les bases de données ne prennent pas toutes en charge SQL initial
  • Incidence possible sur les performances en raison des limitations de partage de la mémoire cache
Merci de vos commentaires !