Row Level Security oubliée : la fuite RGPD que personne ne voit venir

La Row Level Security filtre les lignes visibles selon l'utilisateur connecté. Bien conçue, un directeur régional ne voit que sa région, un commercial que ses comptes. Mal conçue, elle laisse tout passer — et contrairement à un mot de passe refusé, une RLS défaillante ne déclenche aucune alerte. L'utilisateur voit plus de données qu'il ne devrait, sans le savoir, et l'incident reste invisible jusqu'à ce qu'un salarié signale qu'il aperçoit les chiffres d'un collègue.

Les modes d'échec sont nombreux et discrets :

• Filtre utilisateur posé en filtre de vue et non en filtre de source : il se retire d'un clic ou se contourne en dupliquant le workbook.
• USERNAME() comparé à un champ mal normalisé (casse, domaine email) : le filtre ne matche jamais et, selon la logique, laisse tout voir.
• Web Edit ou Download autorisés : l'utilisateur télécharge la source complète, RLS comprise mais données brutes accessibles.
• RLS posée sur le dashboard mais oubliée sur une source secondaire alimentant un autre onglet.

Un piège plus subtil encore : la RLS via groupes de droits dans Tableau Server ou Tableau Cloud, déléguée à l'administration des permissions plutôt qu'au filtrage des données. Tant que l'annuaire est propre, tout va bien. Mais un nouveau collaborateur ajouté au mauvais groupe, une synchronisation d'annuaire qui range les utilisateurs par défaut dans un groupe « Tous », et l'exposition se rouvre sans qu'aucune modification n'ait touché le workbook. Le consultant qui a conçu le mécanisme reste pourtant dans la boucle de responsabilité, car c'est l'architecture de filtrage qu'il a livrée qui s'appuie sur cette hypothèse fragile.

On associe la fuite de données à un piratage externe. Le RGPD, lui, ne fait pas cette distinction. L'article 4-12 définit une violation de données comme tout accès non autorisé à des données personnelles — y compris un accès interne par un salarié non habilité.

Si votre dashboard expose des salaires, des évaluations, des coordonnées de clients ou des données de santé à des collaborateurs qui ne devraient pas les voir, l'organisation fait face à une violation potentiellement notifiable à la CNIL sous 72 heures (article 33), voire aux personnes concernées si le risque est élevé (article 34).

Une RLS oubliée n'est pas une négligence technique anodine : c'est le mécanisme de sécurité défaillant à l'origine d'une violation de données personnelles.

Et le RGPD impose la sécurité « dès la conception et par défaut » (article 25). Le mécanisme de filtrage que vous avez conçu est précisément l'objet de cette exigence.

La question clé : êtes-vous un simple exécutant ou un sous-traitant au sens de l'article 28 du RGPD ? Si vous concevez et déterminez les modalités du traitement de sécurité des données — ce qui est le cas quand vous architecturez la RLS — vous portez des obligations propres et pouvez voir votre responsabilité engagée aux côtés du responsable de traitement.

Concrètement, en cas d'incident :

• Le responsable de traitement (le client) assume la notification et l'éventuelle sanction CNIL.
• Mais il peut se retourner contre vous au titre de votre prestation défaillante, sur le fondement contractuel et au titre de l'article 82 du RGPD qui ouvre l'action récursoire entre acteurs.

Votre RC Pro répond du préjudice causé par votre faute de conception. Mais la gestion technique de l'incident — investigation, mesure de l'exposition, notification — relève d'un autre registre.

Une RLS défaillante crée deux familles de coûts qui n'appellent pas la même couverture :

La garantie cyber finance la gestion opérationnelle de l'incident — souvent la part la plus lourde et la plus urgente, dans la fenêtre des 72 heures. Pour un consultant Tableau qui manipule au quotidien des données nominatives et financières dans les sources de ses clients, coupler RC Pro et cyber n'est pas un luxe mais la réponse au double visage du risque.

La temporalité est décisive. Quand une exposition est découverte, l'organisation a besoin, en quelques heures, de savoir qui a réellement consulté quoi : combien d'utilisateurs ont ouvert le dashboard pendant la période de défaut, quelles lignes étaient visibles, faut-il notifier les personnes concernées. Cette investigation requiert une expertise forensique que ni vous ni le client n'avez en interne, et dont la facture tombe immédiatement. C'est la valeur concrète d'une garantie cyber : elle débloque les moyens d'expertise au moment exact où la pression réglementaire est maximale, sans attendre l'issue, parfois longue, du débat sur la responsabilité. Pendant ce temps, la RC Pro traite, en parallèle et sur un autre tempo, la question de l'indemnisation du préjudice subi par le client.

Avant toute mise en production d'un workbook exposant des données sensibles, formalisez et faites contresigner :

1. Test multi-comptes. Connexion avec au moins trois profils représentatifs, capture des lignes visibles, écart attendu documenté.
2. Filtre posé en source, pas en vue. Vérification que la RLS s'applique au niveau du data source et résiste à la duplication.
3. Web Edit et Download désactivés sur les contenus sensibles, ou validés explicitement par le client par écrit.
4. Normalisation de USERNAME() testée sur la casse et le format réel de l'annuaire.
5. Matrice d'habilitation signée par le client : qui voit quoi, datée et annexée au PV de recette.

Cette traçabilité est votre meilleure défense : elle prouve que la sécurité a été conçue « par défaut » et déplace, en cas de litige, la charge vers un débat où votre couverture vous protège.