Sécurité au niveau des rangées dans Fabric Data Warehouse

S’applique à :✅ point de terminaison analytique SQL et entrepôt dans Microsoft Fabric

La sécurité au niveau des lignes (SNL) vous permet d’utiliser l’appartenance à un groupe ou le contexte d’exécution pour contrôler l’accès aux lignes dans une table de base de données. Par exemple, vous pouvez vous assurer que les collaborateurs accèdent uniquement aux lignes de données qui sont pertinentes pour leur département. Un autre exemple consiste à restreindre l’accès aux données de clients aux seules données relatives à leur entreprise dans une architecture multilocataire. La fonctionnalité est similaire à la sécurité au niveau des lignes dans SQL Server.

Sécurité au niveau des lignes des données

La sécurité au niveau des lignes simplifie la conception et l’implémentation de la sécurité dans votre application. La sécurité au niveau des lignes vous aide à implémenter des restrictions sur l’accès aux lignes de données.

La logique de restriction d’accès se trouve au niveau de la base de données, et non dans un seul niveau d’application. La base de données applique les restrictions d’accès à chaque tentative d’accès aux données, à partir de n’importe quelle application ou plateforme de reporting, y compris Power BI. Cela rend votre système de sécurité plus fiable et robuste en réduisant sa surface d’exposition. La sécurité au niveau des lignes s’applique uniquement aux requêtes sur un entrepôt ou un point de terminaison d’analytique SQL dans Fabric. Les requêtes Power BI sur un entrepôt en mode Direct Lake reviendront au mode Direct Query pour respecter la sécurité au niveau des lignes.

Restreindre l’accès à certaines lignes à certains utilisateurs

Implémentez RLS à l’aide de l’instruction Transact-SQL CREATE SECURITY POLICY, ainsi que de prédicats créés sous forme de fonctions table inline.

La sécurité au niveau des lignes est appliquée à entrepôt partagé ou maison au bord du lac, car la source de données sous-jacente n’a pas changé.

Sécurité au niveau des lignes basée sur les prédictions

La sécurité au niveau des lignes dans l’entrepôt de données Fabric prend en charge la sécurité basée sur les prédicats. Les prédicats de filtrage filtrent silencieusement les lignes disponibles pour les opérations de lecture.

L’accès aux données au niveau des lignes dans une table est restreint par un prédicat de sécurité défini en tant que fonction table incluse. La fonction est ensuite appelée et appliquée par une stratégie de sécurité. Pour les prédicats de filtrage, l’application n’a pas connaissance des lignes exclues du jeu de résultats par le filtre. Si toutes les lignes sont filtrées, un jeu de valeurs null est retourné.

Les prédicats de filtre sont appliqués lors de la lecture des données de la table de base. Ils affectent toutes les opérations Get : SELECT, DELETE et UPDATE. Chaque table doit avoir sa propre sécurité au niveau des lignes définie séparément. Les utilisateurs qui interrogent des tables sans stratégie de sécurité au niveau des lignes affichent des données non filtrées.

Les utilisateurs ne peuvent pas sélectionner ou supprimer des lignes qui sont filtrées. L’utilisateur ne peut pas mettre à jour des lignes qui sont filtrées. Toutefois, il est possible de mettre à jour les lignes de sorte qu’elles seront filtrées par la suite.

Les prédicats de filtre et les stratégies de sécurité ont le comportement suivant :

  • Vous pouvez définir une fonction de prédicat qui crée une jointure avec une autre table et/ou appelle une fonction. Si la stratégie de sécurité est créée avec SCHEMABINDING = ON (valeur par défaut), alors la jointure ou la fonction est accessible à partir de la requête et fonctionne comme prévu, sans aucun contrôle d’autorisation supplémentaire.

  • Vous pouvez émettre une requête sur une table pour laquelle un prédicat de sécurité est défini, mais désactivé. Les lignes qui sont filtrées ou bloquées ne sont pas affectées.

  • Si un utilisateur dbo, membre du rôle db_owner ou le propriétaire de la table interrogent une table pour laquelle une stratégie de sécurité est définie et activée, les lignes sont filtrées ou bloquées conformément à celle-ci.

  • Toute tentative de modification du schéma d’une table liée par une stratégie de sécurité liée au schéma génère une erreur. En revanche, les colonnes non référencées par le prédicat peuvent être modifiées.

  • Toute tentative d’ajouter un prédicat sur une table pour laquelle un prédicat est déjà défini pour l’opération spécifiée génère une erreur. C’est le cas que le prédicat soit activé ou non.

  • Toute tentative de modifier une fonction utilisée comme prédicat sur une table à l’intérieur d’une stratégie de sécurité liée à un schéma génère une erreur.

  • La définition de plusieurs stratégies de sécurité actives contenant des prédicats non chevauchants réussit.

Les prédicats de filtre se comportent comme suit :

  • Définir une stratégie de sécurité qui filtre les lignes d'une table. L’application n’a pas connaissance des lignes qui sont filtrées pour SELECT,UPDATE, et les opérations DELETE. Ceci inclut les situations où toutes les lignes sont filtrées. L’application peut insérer INSERT lignes même si elles seront filtrées lors d’une autre opération.

Autorisations

La création, la modification ou la suppression des stratégies de sécurité nécessite l’autorisation ALTER ANY SECURITY POLICY. La création ou la suppression d’une stratégie de sécurité nécessite l’autorisation ALTER sur le schéma.

En outre, les autorisations suivantes sont requises pour chaque prédicat ajouté :

  • Autorisations SELECT et REFERENCES sur la fonction utilisée comme prédicat.

  • L’autorisation REFERENCES sur la table cible liée à la stratégie.

  • Autorisation REFERENCES sur chaque colonne de la table cible utilisée comme argument.

Les stratégies de sécurité s'appliquent à tous les utilisateurs, y compris les utilisateurs dbo de la base de données. Les utilisateurs dbo peuvent modifier ou supprimer les stratégies de sécurité, mais leurs modifications des stratégies de sécurité peuvent être auditées. Si les membres ayant un rôle d’administrateur, de membre ou de contributeur ont besoin de voir toutes les lignes pour résoudre des problèmes ou valider des données, la stratégie de sécurité doit être rédigée de manière à le permettre.

Si une stratégie de sécurité est créée avec SCHEMABINDING = OFF, alors pour interroger la table cible, les utilisateurs doivent avoir des autorisations SELECTou EXECUTE sur la fonction de prédicat et toutes les autres tables, vues ou fonctions utilisées au sein de la fonction de prédicat. Si une stratégie de sécurité est créée avec SCHEMABINDING = ON (valeur par défaut), alors ces contrôles d’autorisations sont ignorés quand les utilisateurs interrogent la table cible.

Considérations relatives à la sécurité : attaques par canal latéral

Envisagez et préparez les deux scénarios suivants.

Gestionnaire de stratégie de sécurité malveillant

Il est important de noter qu’un administrateur de stratégie de sécurité malveillant, disposant des autorisations suffisantes pour créer une stratégie de sécurité sur une colonne sensible et de l’autorisation de créer ou de modifier des fonctions inline retournant une table, peut s’entendre avec un autre utilisateur disposant des autorisations SELECT sur une table afin de procéder à une exfiltration de données en créant de manière malveillante des fonctions inline retournant une table conçues pour exploiter des attaques par canal auxiliaire afin d’inférer des données. Ces attaques nécessitent une collusion (ou des autorisations excessives accordées à un utilisateur malveillant) et probablement plusieurs itérations de modification de la stratégie (nécessitant l'autorisation de supprimer le prédicat pour rompre la liaison de schéma), de modification des fonctions table inline et d'exécution répétée d'instructions select sur la table cible. Nous vous recommandons de limiter les autorisations au strict nécessaire et de surveiller toute activité suspecte. Les activités telles que la modification constante des stratégies et les fonctions de table inline liées à la sécurité au niveau des lignes doivent être surveillées.

Requêtes élaborées avec soin

Il est possible de provoquer une fuite d’informations en utilisant des requêtes soigneusement élaborées qui utilisent des erreurs pour exfiltrer des données. Par exemple, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; permettrait à un utilisateur malveillant de savoir que le salaire de John Doe est 100 000 $ exactement. Même s'il existe un prédicat de sécurité en vigueur pour empêcher un utilisateur malveillant d'interroger directement le salaire d'autres personnes, l'utilisateur peut déterminer si la requête retourne une exception de division par zéro.

Exemples

Nous pouvons illustrer l’entrepôt de sécurité au niveau des lignes et le point de terminaison d’analytique SQL dans Microsoft Fabric.

L’exemple suivant crée des exemples de tables qui fonctionnent avec Warehouse dans Fabric, mais dans un point de terminaison d’analytique SQL, utilisez des tables existantes. Dans le point de terminaison d’analytique SQL, vous ne pouvez pas utiliser CREATE TABLE, mais vous pouvez utiliser CREATE SCHEMA, CREATE FUNCTION et CREATE SECURITY POLICY.

Dans cet exemple, commencez par créer un schéma sales, une table sales.Orders.

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

Créez un schéma Security, une fonction Security.tvf_securitypredicate et une stratégie de sécurité SalesFilter.

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Pour modifier une fonction de sécurité au niveau de la ligne, vous devez d'abord supprimer la politique de sécurité. Dans le script suivant, nous allons supprimer la stratégie SalesFilter avant d’émettre une instruction ALTER FUNCTION sur Security.tvf_securitypredicate. Ensuite, nous recréons la stratégie SalesFilter.

-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO

-- Alter the function for the SalesRep evaluation
ALTER FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'president@contoso.com';
GO
 
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Étape suivante

Implémenter la sécurité au niveau des lignes dans Fabric Data Warehouse

Contenu connexe

  • Last updated on