i

Description

Vue à travers un trou de serrure : on n'aperçoit que ce que l'ouverture laisse voir, ici un dôme au loin.

Source

Galen Crout · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Sécurité RLS et accès

Ce thème mesure la maîtrise de qui voit quoi : sécurité au niveau des lignes (RLS, statique et dynamique), au niveau des objets (OLS), droits sur les espaces de travail, partage, accès aux…

En bref

Ce thème mesure la maîtrise de qui voit quoi : sécurité au niveau des lignes (RLS, statique et dynamique), au niveau des objets (OLS), droits sur les espaces de travail, partage, accès aux sources, et surtout la preuve que la sécurité fonctionne (tests de rôles, journaux). La conformité (RGPD, classification) est traitée côté matrice PD.

Sur cette page

1. 1. Pourquoi ce thème
2. 2. Ce que mesure le thème
3. 3. Les 5 niveaux
4. 4. Jalons par niveau
5. 5. Lecture détaillée par niveau
   1. 🟢 Niveau 1 — Ouvert
   2. 🟢 Niveau 2 — Rôles statiques
   3. 🟡 Niveau 3 — Dynamique
   4. 🟡 Niveau 4 — Testé et journalisé
   5. 🔴 Niveau 5 — Prouvé
6. 6. Atteinte partielle et notation
7. 7. Passer au niveau suivant
8. 8. Voir aussi

Niveau : 🟢→🔴 · Code thème : RLS

1. Pourquoi ce thème#

Une fuite de données dans un rapport est un incident de sécurité, pas un défaut d'affichage. La RLS d'un modèle sémantique ne s'applique qu'aux utilisateurs ayant le rôle de lecteur : un membre avec droit d'écriture sur l'espace de travail contourne la RLS (comportement documenté ; à revérifier selon version, état 2026-10). La RLS filtre, mais n'empêche pas les inférences (un total non filtré, un nombre de lignes, un visuel de décomposition). Coût de l'ignorer : exposition de données commerciales (marges, concurrents) ou personnelles.

2. Ce que mesure le thème#

• Axe : du partage ouvert à une sécurité conçue, testée et auditée.
• Indicateurs clés : part des modèles contenant des données sensibles protégés par rôle ; nombre de rôles testés automatiquement ; nombre d'utilisateurs avec droits d'écriture non justifiés ; délai de retrait des droits.
• Unités : %, jours.

3. Les 5 niveaux#

4. Jalons par niveau#

5. Lecture détaillée par niveau#

🟢 Niveau 1 — Ouvert#

• Signes : « tout le monde voit tout », rapports partagés par lien, exports libres.
• Gain : zéro friction. Ne garantit pas : la confidentialité.
• Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Rôles statiques#

-- Rôle « Région Nord » sur DIM_COMMERCIAL
[Region] = "Nord"

• Signes : un rôle par périmètre, membres = groupes. Simple, lisible, coûteux à maintenir quand les périmètres changent.
• Gain : première barrière réelle.
• Limite : explosion du nombre de rôles ; erreurs lors des mutations de personnel.
• Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Dynamique#

-- Rôle unique « Périmètre » sur la table de sécurité SEC_USER_PERIMETRE
[Email] = USERPRINCIPALNAME ()

La table de sécurité relie un utilisateur à ses commerciaux/secteurs ; la relation SEC → dimension propage le filtre jusqu'aux faits. Selon le modèle, une relation bidirectionnelle avec Appliquer le filtre de sécurité dans les deux sens est nécessaire, ce qui peut avoir des effets collatéraux : documenter chaque cas.

• Gain : maintenance par données, pas par déploiement.
• Limite : les totaux peuvent diverger entre utilisateurs (voulu) mais surprendre : un directeur voit un total supérieur à celui d'un manager.
• Difficulté : 3/5 · Effort : 3/5.

🟡 Niveau 4 — Testé et journalisé#

• Signes : « voir en tant que » est un test de livraison ; les requêtes d'audit ont un propriétaire ; l'OLS cache les colonnes sensibles (marges) aux rôles non autorisés.
• Gain : une règle fausse est vue avant la prod.
• Limite : l'OLS peut casser des rapports qui référencent la colonne masquée ; le tester.
• Difficulté : 4/5 · Effort : 4/5.

🔴 Niveau 5 — Prouvé#

• Signes : table de sécurité alimentée par la source RH, revue de sécurité indépendante, matrice de contournements (exports, abonnements, API, accès direct à la base ou au lakehouse) testée. La RLS du modèle ne protège pas la source : l'accès direct SQL ou OneLake doit être couvert séparément.
• Gain : preuve opposable.
• Limite : coût de maintenance et de coordination avec RH et sécurité.
• Difficulté : 5/5 · Effort : 5/5.

6. Atteinte partielle et notation#

Règle commune. Un « 5 partiel » : revue indépendante faite une fois mais pas renouvelée (BI-RLS-5.1 = 0,5), table de sécurité alimentée automatiquement (5.2 = 1), étiquettes de sensibilité posées sur la moitié des modèles (5.3 = 0,5), contournements testés sur les exports mais pas sur l'accès direct à la source (5.4 = 0,5). Un jalon de sécurité à 0 bloque l'acquisition du niveau, quelle que soit la moyenne : c'est voulu.

7. Passer au niveau suivant#

Moyens possibles (facultatifs) :

Pièges :

• Faux positif : « la RLS est en place » mais les administrateurs et l'équipe projet ne la testent jamais avec un compte lecteur.
• Goodhart : compter les rôles ; un rôle « Tous » qui ne filtre rien rend la mesure creuse.
• Confondre confidentialité et masquage : cacher un visuel n'est pas sécuriser la donnée sous-jacente.

8. Voir aussi#

• Thèmes voisins : MOD · TST · GOV · IND
• Autres matrices : PD — sécurité, confidentialité, conformité · DL — sécurité
• Contenus : SQL Server SaaS — difficultés et pièges · OneLake — difficultés et pièges · Checklist de projet reporting

✻ Rédigé par Claude Sonnet 5.5