Sécurité End-to-End pour le Data Warehousing
dans Microsoft Fabric

Jean-Marie SADIO

Data Engineer — Microsoft Fabric & Snowflake

01. Introduction — Pourquoi la sécurité dans Fabric Warehouse

À la FabCon + SQLCon Atlanta 2026 (16-20 mars), Shabnam Watson — Microsoft Data Platform MVP et Principal Consultant chez ABI Cube — a présenté une session dense et extrêmement pratique sur la sécurité end-to-end pour le Data Warehousing dans Microsoft Fabric. En tant que Data Engineer, c'etait l'une des sessions que j'attendais le plus.

La raison est simple : dans Fabric, le Warehouse est souvent le point d'accès principal aux données pour les analystes, les data scientists et les outils de reporting. C'est là où convergent les données sensibles. Et pourtant, beaucoup d'équipes déploient leurs Warehouses avec les paramètres par défaut, sans implémenter les couches de sécurité avancées disponibles.

Voici mon récap complet de cette session, avec tous les exemples de code et les recommandations pratiques que Shabnam a partagées.

02. Microsoft Entra ID — La fondation identitaire

Tout commence par l'identité. Dans Fabric, Microsoft Entra ID (anciennement Azure AD) est le socle de toute la chaîne de sécurité. Chaque utilisateur, chaque service principal, chaque application qui accède à Fabric doit être authentifié via Entra ID.

Single Sign-On et protocoles

Fabric s'appuie sur le SSO (Single Sign-On) via Entra ID. Les protocoles utilisés sont :

• OAuth 2.0 — pour l'autorisation d'accès aux ressources Fabric
• OpenID Connect — pour l'authentification des utilisateurs, construit au-dessus d'OAuth 2.0

Concrètement, quand un utilisateur se connecte au portail Fabric ou qu'un pipeline accède à un Warehouse via un Service Principal, un token OAuth est émis par Entra ID. Ce token contient les claims d'identité et les permissions associées.

Conditional Access Policies

Shabnam a insisté sur l'importance des Conditional Access Policies — des règles Entra ID qui permettent de conditionner l'accès à Fabric en fonction de critères comme :

• L'emplacement réseau — bloquer l'accès depuis des IPs non approuvées
• Le type d'appareil — exiger un appareil managé (Intune)
• Le niveau de risque — bloquer les connexions à risque élevé détectées par Identity Protection
• La MFA — imposer l'authentification multi-facteurs systématiquement

03. Network Security — Private Links, VNet et accès public

La deuxième couche de sécurité concerne le réseau. Shabnam a décomposé la sécurité réseau en deux axes : Inbound (qui peut atteindre Fabric) et Outbound (où Fabric peut envoyer des données).

Sécurité Inbound : Private Links et Endpoints

Par défaut, Fabric est accèssible depuis Internet public. Pour verrouiller cet accès, deux mécanismes complémentaires existent :

Sécurité Outbound : VNet Integration

Pour le trafic sortant (Fabric vers vos sources de données), la VNet integration permet à Fabric d'accéder à vos ressources Azure via un réseau privé, sans passer par Internet :

• Managed VNet — Fabric gère le VNet automatiquement, vous configurez des Managed Private Endpoints vers vos ressources (SQL Server, Storage Account, etc.)
• Trusted workspace accèss — autorise Fabric à accéder à des ressources Azure protégées par un firewall, sans Private Endpoint, en se basant sur l'identité du workspace

04. Workspace Roles — Admin, Member, Contributor, Viewer

Une fois l'identité et le réseau sécurisés, on passe aux permissions au niveau workspace. Fabric propose quatre roles de workspace, chacun avec des capacites spécifiques :

Point important soulevé par Shabnam : les rôles workspace s'appliquent à tous les items du workspace. Si un utilisateur est Viewer sur le workspace, il voit tous les items (Warehouses, Lakehouses, notebooks, rapports...). Pour un contrôle plus fin, il faut passer aux permissions au niveau item.

05. Item-Level Permissions — Contrôle granulaire par objet

Les item-level permissions permettent de donner accès à un objet spécifique (un Warehouse, un Lakehouse, un rapport) sans donner accès à tout le workspace. C'est essentiel pour les scénarios multi-équipes.

Les quatre permissions item-level

Partage avec des non-membres du workspace

Un point clé de la présentation : vous pouvez partager un Warehouse avec un utilisateur qui n'a aucun role dans le workspace. L'utilisateur recoit uniquement les permissions item-level que vous choisissez (Connect, ReadData, ReadAll). Il ne voit pas les autres items du workspace.

-- Acceder aux données via le SQL Endpoint avec les permissions ReadData
SELECT *
FROM OPENROWSET(
    'CosmosDB',
    'Account=myaccount;Database=mydb',
    Products
) AS query1;

-- Verifier les permissions effectives de l'utilisateur courant
SELECT * FROM sys.fn_my_permissions('dbo.FactSales', 'OBJECT');

06. SQL-Level Permissions — OLS, CLS, RLS avec exemples

C'est le cœur de la session. Shabnam a détaillé les trois mécanismes de sécurité au niveau SQL qui permettent un contrôle granulaire sur qui voit quoi dans le Warehouse.

Object Level Security (OLS)

L'OLS permet de contrôler l'accès aux objets SQL entiers (tables, vues, schemas) via les commandes classiques GRANT, DENY et REVOKE.

-- Accorder le droit SELECT sur une table à un utilisateur
GRANT SELECT ON dbo.FactSales TO [analyst@contoso.com];

-- Refuser le droit SELECT sur une table sensible
DENY SELECT ON dbo.DimEmployee TO [junior_analyst@contoso.com];

-- Révoquer un droit précédemment accordé
REVOKE SELECT ON dbo.FactSales FROM [contractor@external.com];

-- Accorder SELECT sur tout un schéma
GRANT SELECT ON SCHEMA::reporting TO [reporting_team@contoso.com];

Column Level Security (CLS)

Le CLS va plus loin : il restreint l'accès à des colonnes spécifiques au sein d'une table. L'utilisateur peut voir la table, mais certaines colonnes lui sont masquées.

-- Masquer la colonne Salary pour les analystes
DENY SELECT ON dbo.DimEmployee(Salary) TO [analyst@contoso.com];

-- Masquer plusieurs colonnes sensibles
DENY SELECT ON dbo.DimEmployee(Salary, SSN, BankAccount)
    TO [analyst@contoso.com];

-- L'utilisateur peut toujours interroger les autres colonnes
-- SELECT EmployeeID, Name, Department FROM dbo.DimEmployee; -- OK
-- SELECT Salary FROM dbo.DimEmployee; -- ERREUR : permission refusée

Row Level Security (RLS)

Le RLS est le mécanisme le plus puissant : il filtre les lignes retournées en fonction de l'identité de l'utilisateur connecté. La mise en place se fait en trois étapes : créer un schéma, créer une fonction de filtre, puis créer une politique de sécurité.

-- Étape 1 : Créer un schéma dédié pour les fonctions de sécurité
CREATE SCHEMA Security;
GO

-- Étape 2 : Créer la fonction de filtre
-- Cette fonction retourne 1 (autoriser) si l'utilisateur connecté
-- correspond au SalesRep de la ligne, ou s'il est manager
CREATE FUNCTION Security.fn_securitypredicate(
    @SalesRep AS NVARCHAR(256)
)
RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS fn_securitypredicate_result
    WHERE @SalesRep = USER_NAME()
       OR USER_NAME() = 'manager@contoso.com';
GO

-- Étape 3 : Créer la politique de sécurité et l'appliquer à la table
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.fn_securitypredicate(SalesRep)
    ON dbo.FactSales
WITH (STATE = ON);
GO

07. Dynamic Data Masking — Masquer les données sensibles

Le Dynamic Data Masking (DDM) ne filtre pas les lignes ou les colonnes — il masque les valeurs retournées. L'utilisateur voit la colonne, mais la valeur est remplacee par un masque. Quatre fonctions de masquage sont disponibles :

CREATE TABLE dbo.Employees (
    EmployeeID    INT           NOT NULL,
    FirstName     NVARCHAR(50)  MASKED WITH (FUNCTION = 'default()'),
    LastName      NVARCHAR(50)  MASKED WITH (FUNCTION = 'default()'),
    Email         NVARCHAR(100) MASKED WITH (FUNCTION = 'email()'),
    Phone         NVARCHAR(15)  MASKED WITH (FUNCTION = 'partial(2, "XXXX", 2)'),
    Salary        DECIMAL(10,2) MASKED WITH (FUNCTION = 'random(10000, 99999)'),
    Department    NVARCHAR(50)
);

-- Accorder la permission de voir les données non masquées
GRANT UNMASK TO [hr_manager@contoso.com];

-- Révoquer la permission UNMASK
REVOKE UNMASK FROM [analyst@contoso.com];

08. Warnings & Gotchas — Les pièges à éviter

C'est la partie de la session qui m'a le plus marqué. Shabnam a partage plusieurs pièges concrets que les équipes rencontrent en production.

-- Lister toutes les permissions SQL accordées
SELECT
    dp.name            AS principal_name,
    dp.type_desc       AS principal_type,
    perm.permission_name,
    perm.state_desc,
    OBJECT_NAME(perm.major_id) AS object_name
FROM sys.database_permissions perm
JOIN sys.database_principals dp
    ON perm.grantee_principal_id = dp.principal_id
WHERE dp.type IN ('S', 'E', 'X')
ORDER BY dp.name;

09. Audit Logs — Tracer et surveiller les accès

La dernière couche de defense : les Audit Logs. Ils ne bloquent rien, mais ils tracent tout. Shabnam a insisté : sans audit logs, vous ne savez pas ce qui se passe réellement dans votre Warehouse.

Ce que les Audit Logs tracent

• Connexions — qui se connecte, quand, depuis quelle IP
• Requêtes exécutées — les SELECT, INSERT, UPDATE, DELETE sur les objets
• Modifications de permissions — les GRANT, DENY, REVOKE
• Modifications de schéma — CREATE, ALTER, DROP sur les tables et vues
• Accès aux données sensibles — les tentatives d'accès à des objets protégés par RLS/CLS

Où vivent les Audit Logs

Dans Fabric, les audit logs sont centralises dans le Microsoft 365 Unified Audit Log. Ils sont accèssibles via :

• Microsoft Purview Compliance Portal — interface web pour rechercher et exporter les logs
• PowerShell — cmdlets Search-UnifiedAuditLog pour l'automatisation
• API Office 365 Management Activity — pour intégrer les logs dans un SIEM (Sentinel, Splunk, etc.)

Mise en place

Les audit logs doivent être activés au niveau du tenant par un admin Microsoft 365. Une fois activés, ils capturent automatiquement les événements Fabric. Il est recommandé de configurer des alertes sur les événements critiques (ex : modification de permissions, tentatives d'accès refusées).

10. Best Practices — Les recommandations clés

Shabnam a conclu sa session avec un récapitulatif des best practices. Voici les 10 recommandations que je retiens :

Cette session de Shabnam Watson était l'une des meilleures que j'ai suivies à la FabCon Atlanta 2026. En tant que Data Engineer, j'ai souvent tendance à me concentrer sur les pipelines et les transformations — mais la sécurité mérite la même rigueur. Les exemples de code sont directement applicables, et les "gotchas" partagées par Shabnam évitent des erreurs coûteuses.

Mon plan d'action personnel après cette session : auditer les permissions SQL orphelines sur nos Warehouses de production, implémenter le RLS sur notre table FactSales, et configurer des alertes sur les modifications de permissions dans les audit logs.

Retrouvez-moi sur LinkedIn pour en discuter. Et si vous étiez à la FabCon, dites-moi quelles sessions vous ont le plus marqué !