🔒 Mettre en place le Row-Level Security (RLS) : La clé d’une donnée bien gouvernée !
Garantir que chaque utilisateur accède uniquement aux informations qui lui sont destinées est un enjeu clé. Le Row-Level Security (RLS) s’impose alors comme un levier essentiel pour renforcer la sécurité des dashboards tout en optimisant l’expérience utilisateur.
Voyons comment le mettre en place efficacement ! 👇
🔹 Les avantages du RLS ?
- ✅ Confidentialité : Restreindre l’accès aux données sensibles en fonction des rôles utilisateurs.
- ✅ Performance : Éviter les extractions multiples en filtrant dynamiquement les données.
- ✅ Expérience utilisateur : Offrir une vue personnalisée et pertinente à chaque utilisateur.
Sans RLS, tout le monde a accès à tout. Mauvaise idée dans un environnement bancaire ou assurantiel par exemple !
🛠️ Méthodes d’implémentation du RLS sur Tableau
1️⃣ Via les filtres utilisateurs dans Tableau Server
Le plus simple, mais limité :
- Créez un filtre utilisateur dans Tableau Desktop.
- Associez chaque utilisateur à des permissions spécifiques via un champ comme
username()
. - Appliquez ce filtre dans vos vues.
📌 Limites : Moins scalable si vous gérez des centaines d’utilisateurs avec des droits complexes.
2️⃣ Avec une relation sur une table d’autorisations
Méthode recommandée pour des règles plus fines :
- Créez une table contenant :
- user_id | region
- u_001 | Europe
- u_002 | Amérique
- user_id | region
- Reliez cette table à vos données transactionnelles (
region
dans cet exemple) via une simple relation logique (plus adapté et performant dans ce cas précis qu’une jointure physique). - Appliquez un filtre conditionnel basé sur
username()
côté feuille de calcul.
📌 Avantages : Facile à maintenir, surtout si les autorisations évoluent !
🚀 Optimisation envisageable: ajout d’une colonne id_region pour faire la jointure sur un nombre et non une chaîne de caractères
3️⃣ En passant par une vue SQL sécurisée
Si vous avez la main sur la base de données, c’est une solution ultra-efficace :
- Créez une vue SQL qui filtre les données en fonction de l’utilisateur connecté.
- Ex. sous PostgreSQL, connectez Tableau à cette vue filtrée.
CREATE VIEW secure_data AS
SELECT *
FROM sales_data
WHERE region IN ( SELECT region FROM user_permissions WHERE user_id = CURRENT_USER );
Bien sûr ici il faudra envoyer à votre base de données l’id de session utilisateur (CURRENT_USER) depuis Tableau. Pour cela vous pouvez utiliser l’option Tableau « SQL Initial » et y passer la commande suivante:
SET session "app.tableau_username"=[TableauServerUser];
Ainsi, vous pourrez récupérer votre CURRENT_USER côté base de données (ici PostgreSql) via:
SELECT current_setting('app.tableau_username',true);
📌 Idéal pour des datasets volumineux car la restriction se fait côté base. Les performances peuvent cependant dépendre grandement de la configuration/restriction appliquée sur votre SGBD.
🎯 Bonnes pratiques pour un RLS efficace
🔹 Centralisez les règles dans une table ou une vue SQL plutôt que de les dupliquer dans Tableau.
🔹 Verrouillez les extractions statiques, qui risquent de ne pas refléter les mises à jour de permissions.
🔹 Testez les accès avec différents profils utilisateurs pour éviter les fuites de données et évaluer les temps de réponse de façon réaliste.
🚀 Et après ?
Le RLS, c’est un must-have pour sécuriser vos dashboards et éviter que Jean-Michel du Marketing ne voie les données confidentielles de Paul en Finance. 😅
💬 Et vous, utilisez-vous le RLS sur vos dashboards Tableau ? Partagez vos retours en commentaire ! 👇
hello,
Interessant 🙂 Merci pour ces explivations.