Présentation des politiques d’accès aux lignes

Cette rubrique présente une introduction aux politiques d’accès aux lignes et à la sécurité au niveau des lignes.

Dans ce chapitre :

Qu’est-ce que la sécurité au niveau des lignes ?

Snowflake prend en charge la sécurité au niveau des lignes en utilisant des politiques d’accès aux lignes pour déterminer les lignes à retourner dans le résultat de la requête. La politique d’accès aux lignes peut être relativement simple pour permettre à un rôle particulier de visualiser les lignes, ou plus complexe pour inclure une table de mappage dans la définition de la politique afin de déterminer l’accès aux lignes dans le résultat de la requête.

Une politique d’accès aux lignes est un objet de niveau schéma qui détermine si une ligne donnée d’une table ou d’une vue peut être visualisée à partir des types d’instructions suivants :

Les politiques d’accès aux lignes peuvent inclure des conditions et des fonctions dans l’expression de la politique pour transformer les données lors de l’exécution de la requête lorsque ces conditions sont remplies. L’approche axée sur les politiques prend en charge la séparation des tâches pour permettre aux équipes de gouvernance de définir des politiques qui peuvent limiter l’exposition des données sensibles. Cette approche inclut également le propriétaire de l’objet (c’est-à-dire le rôle ayant le privilège OWNERSHIP sur l’objet, tel qu’une table ou une vue) qui a normalement un accès complet aux données sous-jacentes. Une seule politique peut être définie sur différentes tables et vues en même temps.

The row access policy admin can apply row access policies to tables and views.

Les politiques d’accès aux lignes n’empêchent pas actuellement l’insertion de lignes, ni la mise à jour ou la suppression de lignes visibles.

Une politique d’accès aux lignes peut être ajoutée à une table ou à une vue soit lors de la création de l’objet, soit après la création de l’objet. Pour plus d’informations, voir, Appliquer une politique d’accès aux lignes à une table ou à une vue (dans cette rubrique).

Comment fonctionne une politique d’accès aux lignes ?

Une politique d’accès aux lignes contient une expression qui peut spécifier des objets de base de données Snowflake (par exemple, une table ou une vue) et utiliser Fonctions d’expressions conditionnelles et Fonctions contextuelles pour déterminer quelles lignes doivent être visibles dans un contexte donné.

Snowflake évalue l’expression de politique en utilisant le rôle du propriétaire de la politique, et non le rôle de l’opérateur qui a exécuté la requête. Cette approche permet à Snowflake de ne pas renvoyer de ligne dans le résultat d’une requête, car l’opérateur de requête n’a pas besoin d’accéder aux tables de mappage dans la politique d’accès aux lignes.

Astuce

Si vous souhaitez mettre à jour une politique d’accès aux lignes existante et si vous avez besoin de voir la définition actuelle de cette politique, appelez la fonction GET_DDL ou exécutez la commande DESCRIBE ROW ACCESS POLICY .

L’expression de la politique d’accès aux lignes peut alors être mise à jour avec la commande ALTER ROW ACCESS POLICY. Cette commande ne nécessite pas la destruction d’une politique d’accès aux lignes d’une table ou d’une vue. Ainsi, une table ou une vue protégée par une politique d’accès aux lignes le reste lors de la mise à jour de l’expression de la politique.

Politiques d’accès aux lignes au moment de l’exécution de la requête

Au moment de l’exécution de la requête, Snowflake suit le processus suivant :

  1. Snowflake détermine si une politique d’accès aux lignes est définie sur un objet de base de données. Si une politique est ajoutée à l’objet de la base de données, toutes les lignes sont protégées par la politique.

  2. Snowflake crée une vue dynamique sécurisée (c’est-à-dire une vue en ligne sécurisée) de l’objet de la base de données.

  3. Les valeurs des colonnes spécifiées dans la commande ALTER TABLE ou ALTER VIEW (c’est-à-dire lors de l’ajout d’une politique d’accès aux lignes à une table ou à une vue) sont liées aux paramètres correspondants de la politique, et l’expression de la politique est évaluée.

  4. Snowflake génère la sortie de la requête pour l’utilisateur, et la sortie de la requête ne contient que des lignes basées sur la définition de la politique évaluant TRUE.

Pour plus de détails sur le plan d’exécution spécifique, voir Profil de requête (dans cette rubrique).

Snowflake prend en charge les politiques d’accès aux lignes imbriquées, telles qu’une politique d’accès aux lignes sur une table et une politique d’accès aux lignes sur une vue pour la même table. Au moment de l’exécution de la requête, Snowflake évalue toutes les politiques d’accès aux lignes pertinentes pour une requête donnée dans l’ordre suivant :

  • La politique d’accès aux lignes applicable à la table est toujours exécutée en premier.

  • La politique de la vue est exécutée après avoir évalué la politique de la table.

  • S’il existe des vues imbriquées (par exemple Table 1 -> Vue 1 -> Vue 2 -> … Vue n), les politiques sont appliquées dans un ordre séquentiel de gauche à droite.

Ce modèle se poursuit selon le nombre de politiques d’accès aux lignes qui existent en ce qui concerne les données de la requête. Le diagramme suivant illustre la relation entre un opérateur de requête, des tables, des vues et des politiques.

Row access policies with tables and views.

Pour plus d’informations sur les privilèges de la politique d’accès aux lignes, les commandes et une mise en œuvre étape par étape, voir :

Cas d’utilisation représentatif : filtrage simple des lignes

Une application simple d’une politique d’accès aux lignes consiste à spécifier un attribut dans la politique et un rôle autorisé à voir cet attribut dans le résultat de la requête. L’avantage de politiques simples comme celle-ci est que l’évaluation de ces politiques par Snowflake pour renvoyer les résultats des requêtes a un coût de performance négligeable par rapport à l’utilisation de politiques d’accès aux lignes avec des tables de mappage.

A titre d’exemple représentatif, il peut être nécessaire pour les administrateurs des technologies de l’information (par exemple, le rôle personnalisé it_admin) d’interroger le numéro d’identification d’un employé (c’est-à-dire empl_id) avant d’accorder à l’employé des privilèges supplémentaires pour utiliser les systèmes internes. Par conséquent, la politique d’accès aux lignes doit renvoyer des lignes dans le résultat de la requête si le CURRENT_ROLE correspond au rôle personnalisé it_admin et ne pas renvoyer de lignes pour tous les autres rôles. Par exemple :

CREATE OR REPLACE ROW ACCESS POLICY rap_it
AS (empl_id varchar) RETURNS BOOLEAN ->
  'it_admin' = current_role()
;
Copy

Cette politique est la version la plus concise d’une politique d’accès aux lignes car il n’y a pas d’autres conditions à évaluer, seulement la valeur de CURRENT_ROLE.

Si la hiérarchie des rôles doit être prise en compte, cette politique pourrait de la même manière utiliser IS_ROLE_IN_SESSION pour que les autres rôles puissent voir le numéro d’ID de l’employé dans le résultat de la requête.

Par ailleurs, pour prendre en compte des conditions supplémentaires, l’utilisation de la fonction CASE permet d’inclure des clauses WHEN/THEN/ELSE pour prendre en charge une logique conditionnelle plus détaillée.

Cas d’utilisation représentatif : utiliser une table de mappage pour filtrer le résultat de la requête

Une condition de politique d’accès aux lignes peut faire référence à une table de mappage pour filtrer le jeu de résultats de la requête. Toutefois, l’utilisation de tables de mappage peut entraîner une baisse des performances par rapport à l’exemple plus simple .

Par exemple, utilisez une table de mappage pour déterminer les valeurs de revenus qu’un directeur des ventes peut voir dans une région de vente donnée. La table de mappage doit spécifier le directeur des ventes et la région de vente (par exemple, WW: Worldwide, NA: North America, EU: European Union).

Directeur des ventes

Région

Alice

WW

Bob

NA

Simon

EU

Ensuite, définissez une politique avec une ou plusieurs conditions pour interroger la table de mappage avec une sous-requête. Au moment de l’exécution de la requête, Snowflake détermine si l’utilisateur qui l’exécute correspond à la région de vente spécifiée dans la table de mappage.

Si une correspondance se produit, l’utilisateur peut voir ces lignes dans le résultat de la requête. Sur la base de la table de mappage, les résultats attendus de la requête sont les suivants :

Entreprise

Région

Revenu

Qui peut consulter

Acme

EU

2,5 B

Alice, Simon

Acme

NA

1,5 B

Alice, Bob

Pour plus de détails sur la mise en œuvre d’une politique d’accès aux lignes avec une table de mappage, voir :

Lignes directrices sur les performances des politiques

Les politiques d’accès aux lignes sont conçues pour fonctionner correctement dans une grande variété de scénarios du monde réel. Utilisez les conseils suivants pour sécuriser les données et améliorer les performances :

Limiter les arguments des politiques

Snowflake doit analyser les colonnes auxquelles la politique est liée, même si elles ne sont pas référencées dans les requêtes. Par conséquent, les politiques comportant moins d’arguments seront généralement plus performantes que les politiques comportant de nombreux arguments.

Simplifier l’expression SQL

Les politiques comportant des expressions SQL simples, comme les instructions CASE, sont généralement plus performantes que les politiques qui accèdent à des tables de mappage (c’est-à-dire de consultation). La réduction du nombre de consultations de tables améliore les performances.

Lorsque vous spécifiez une table de mappage, remplacez la référence de la table de mappage par une fonction mémoïsable. Pour plus de détails, reportez-vous à :

Tester avec des charges de travail réalistes

Sans politique d’accès aux lignes, la requête SELECT COUNT(*) FROM t1 s’exécute en quelques millisecondes puisque Snowflake connaît déjà le nombre de lignes dans la table. Cependant, l’ajout d’une politique d’accès aux lignes signifie que Snowflake doit analyser la table pour compter le nombre de lignes qui sont accessibles dans le contexte actuel. Bien que la différence de performance soit importante, cette requête n’est pas représentative de la plupart des charges de travail du monde réel.

Pour plus d’informations sur cet exemple, voir la section Considérations (dans cette rubrique).

Regrouper par attributs

Pour les très grandes tables, le regroupement (clustering) par attributs utilisé pour le filtrage des politiques peut améliorer les performances.

Pour plus d’informations, voir Clés de clustering et tables en cluster.

Service d’optimisation de la recherche

Le service d’optimisation de la recherche peut améliorer les performances des requêtes sur une table qui utilise une politique de masquage ou d’accès aux lignes.

Pour plus de détails, voir Prise en charge des tables avec des politiques de masquage et des politiques d’accès aux lignes dans le service d’optimisation de la recherche.

Avantages

Le principal avantage d’une politique d’accès aux lignes est qu’elle permet à une organisation d’équilibrer correctement la sécurité des données, la gouvernance et l’analyse grâce à une politique extensible. La nature extensible de la politique d’accès aux lignes permet d’ajouter ou de supprimer une ou plusieurs conditions à tout moment afin de garantir la cohérence de la politique avec les mises à jour des données, des tables de mappage et la hiérarchie RBAC.

Les avantages supplémentaires comprennent :

Facilité d’utilisation

Rédigez une politique une seule fois et appliquez-la aux tables dans toutes les bases de données et tous les schémas.

Gestion du changement

Modifiez facilement les définitions des politiques d’accès aux lignes sans avoir à réappliquer la politique aux tables.

Si vous utilisez une table de mappage, mettez à jour les informations sur les droits dans la table de mappage référencée par la politique sans avoir à modifier la politique.

Administration des données et SoD

C’est un administrateur central des données qui décide des objets à protéger, et non le propriétaire de l’objet. Les politiques d’accès aux lignes sont faciles à gérer et à prendre en charge par le biais de modèles d’administration centralisés, décentralisés et hybrides afin de prendre en charge la séparation des tâches (c’est-à-dire SoD).

Autorisation et gouvernance des données

La politique d’accès aux lignes prend en charge l’accès aux données contextuelles par rôle ou droits personnalisés.

Limites

  • L’utilisation de la clause CHANGES sur une vue protégée par une politique d’accès aux lignes n’est pas prise en charge.

  • Snowflake ne prend pas en charge l’utilisation de tables externes comme table de mappage dans une politique d’accès aux lignes. Pour plus d’informations, voir Tables externes (dans ce chapitre).

  • Snowflake ne prend pas en charge l’attachement d’une politique d’accès aux lignes à l’objet de flux lui-même, mais applique la politique d’accès aux lignes à la table lorsque le flux accède à une table protégée par une politique d’accès aux lignes. Pour plus d’informations, voir Flux (dans ce chapitre).

  • Les autorisations futures de privilèges sur les politiques d’accès aux lignes ne sont pas prises en charge.

    Comme solution de contournement, accordez le privilège APPLYROW ACCESS POLICY à un rôle personnalisé pour lui permettre d’appliquer des politiques d’accès aux lignes d’une table ou d’une vue.

Considérations

  • Attacher des politiques d’accès aux lignes à des tables qui sont protégées par d’autres politiques d’accès aux lignes ou par des politiques de masquage peut provoquer des erreurs. Pour plus d’informations, voir ALTER TABLE, ALTER EXTERNAL TABLE, et ALTER VIEW.

  • L’inclusion d’une ou plusieurs sous-requêtes dans le corps de la politique peut provoquer des erreurs. Dans la mesure du possible, limitez le nombre de sous-requêtes, limitez le nombre d’opérations JOIN et simplifiez les conditions des clauses WHERE.

  • Snowflake maintient des statistiques sur les colonnes des tables et des vues qui permettent de répondre à de nombreuses requêtes simples en quelques millisecondes. Des exemples de telles requêtes incluent l’utilisation de la fonction COUNT , select count(*) from my_table, et de la fonction MAX , select max(c) from my_table.

    En général, ces statistiques et optimisations ne sont pas applicables avec une politique d’accès aux lignes puisque Snowflake doit identifier le sous-ensemble de lignes auquel la requête est autorisée à accéder. L’exécution de requêtes de ce type sur des tables et des vues avec une politique d’accès aux lignes peut prendre plus de temps que prévu pour obtenir les résultats de la requête car ces statistiques et optimisations ne sont pas utilisées, et les statistiques renvoyées sont uniquement basées sur ce à quoi il est permis d’accéder, et non sur les « vraies » valeurs statistiques (c’est-à-dire les statistiques sur la table ou la vue sans politique d’accès aux lignes).

  • Lorsque la politique appelle la fonction CURRENT_DATABASE ou CURRENT_SCHEMA, la fonction évalue la base de données ou le schéma qui contient la table ou la vue protégée, et non la base de données ou le schéma de la session que vous spécifiez avec une commande USE <objet> ou que vous sélectionnez avec le sélecteur de contexte dans Snowsight.

Utilisez des politiques d’accès aux lignes avec les objets et fonctionnalités Snowflake

Les sections suivantes décrivent comment les politiques d’accès aux lignes affectent les tables et les vues ainsi que d’autres fonctionnalités de Snowflake.

Obtenez des objets de la base de données avec une politique d’accès aux lignes

La fonction de la table Information Schema POLICY_REFERENCES peut renvoyer des informations sur la politique d’accès aux lignes attribuée à un objet donné.

  • Tous les objets pour une politique donnée :

    Spécifiez le nom de la politique d’accès aux lignes (par exemple, mydb.policies.rap1) :

    SELECT *
    FROM TABLE(
      mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
        POLICY_NAME=>'mydb.policies.rap1'
      )
    );
    
    Copy
  • La politique affectée à un objet spécifique :

    Spécifiez le nom de l’objet (par exemple mydb.tables.t1) et le domaine de l’objet (par exemple table) :

    SELECT *
    FROM TABLE(
      mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
        REF_ENTITY_NAME => 'mydb.tables.t1',
        REF_ENTITY_DOMAIN => 'table'
      )
    );
    
    Copy

Notez que cette fonction de table est complémentaire à la vue Account Usage POLICY_REFERENCES.

Hiérarchie des rôles actifs et tables de mappage

Les conditions de la politique peuvent évaluer directement les rôles principaux et secondaires actifs de l’utilisateur dans une session, rechercher des rôles actifs dans une table de mappage ou faire les deux selon la façon dont l’administrateur de la politique veut écrire la politique.

Pour ces cas d’utilisation, Snowflake recommande d’écrire les conditions de la politique pour appeler la fonction de contexte IS_ROLE_IN_SESSION. Pour des exemples de politiques, voir la section Exemples de la fonction IS_ROLE_IN_SESSION.

Appliquez une politique d’accès aux lignes à une table ou à une vue

Il existe deux options pour ajouter une politique d’accès aux lignes à une table ou à une vue :

  1. Avec une table ou une vue nouvelle, appliquez la politique à une table avec une instruction CREATE TABLE ou à une vue avec une instruction CREATE VIEW.

  2. Avec une table ou une vue existante, appliquez la politique à une table avec une instruction ALTER TABLE ou une vue avec une instruction ALTER VIEW.

Pour une table ou une vue nouvelle, exécutez les instructions suivantes :

-- table
CREATE TABLE sales (
  customer   varchar,
  product    varchar,
  spend      decimal(20, 2),
  sale_date  date,
  region     varchar
)
WITH ROW ACCESS POLICY sales_policy ON (region);

-- view
CREATE VIEW sales_v WITH ROW ACCESS POLICY sales_policy ON (region)
AS SELECT * FROM sales;
Copy

Pour une table ou une vue existante, exécutez les instructions suivantes :

-- table

ALTER TABLE t1 ADD ROW ACCESS POLICY rap_t1 ON (empl_id);

-- view

ALTER VIEW v1 ADD ROW ACCESS POLICY rap_v1 ON (empl_id);
Copy

Politiques de masquage

Lorsqu’un objet de base de données possède à la fois une politique d’accès aux lignes et une ou plusieurs politiques de masquage, Snowflake évalue d’abord la politique d’accès aux lignes.

Une colonne de table ou de vue donnée peut être spécifiée soit dans une signature de politique d’accès aux lignes, soit dans une signature de politique de masquage. En d’autres termes, la même colonne ne peut pas être spécifiée à la fois dans une signature de politique d’accès aux lignes et dans une signature de politique de masquage.

Pour plus d’informations, voir CREATE MASKING POLICY et CREATE ROW ACCESS POLICY.

Simulez le fonctionnement d’une politique

Appelez la fonction POLICY_CONTEXT pour simuler une requête sur une colonne protégée par une politique de masquage, une table ou une vue protégée par une politique d’accès aux lignes, ou les deux types de politiques.

Tables externes

Vous pouvez créer une table externe avec une politique d’accès aux lignes en exécutant une instruction CREATE EXTERNAL TABLE et en appliquant la politique à la colonne VALUE.

Vous pouvez appliquer la politique d’accès aux lignes à la colonne VALUE de la table externe en exécutant une instruction ALTER TABLE sur la table externe.

Une politique d’accès aux lignes ne peut pas être ajoutée directement à une colonne virtuelle. À la place, créez une vue sur la table externe et appliquez une politique d’accès aux lignes aux colonnes de la vue.

Important

Snowflake ne prend pas en charge l’utilisation d’une table externe comme table de mappage dans une politique d’accès aux lignes. Lors du clonage d’une base de données, Snowflake clone la politique d’accès aux lignes, mais pas la table externe. Par conséquent, la politique dans la base de données clonée fait référence à une table qui n’est pas présente dans la base de données clonée.

Si les données de la table externe sont nécessaires pour la politique d’accès aux lignes, envisagez de déplacer les données de la table externe vers un schéma dédié de la base de données dans laquelle la politique d’accès aux lignes existe avant de réaliser une opération de clonage. Mettez à jour la politique d’accès aux lignes pour faire référence au nom de table entièrement qualifié afin de vous assurer que la politique fait référence à une table dans la base de données clonée.

Flux

Si une politique d’accès aux lignes est ajoutée à une table, Snowflake applique la politique d’accès aux lignes aux données de la table lorsque le flux accède aux données de la table.

Pour plus d’informations, voir Limites.

Vues

Snowflake prend en charge la définition de politiques d’accès aux lignes sur la table et la vue de base. La politique de la table ou de la vue de base peut s’appliquer au propriétaire de la vue (c’est-à-dire INVOKER_ROLE) ou au rôle d’opérateur de requête (c’est-à-dire CURRENT_ROLE).

Pour plus d’informations, voir Limites.

Vues matérialisées

Snowflake prend en charge l’ajout d’une politique d’accès aux lignes à une vue matérialisée à condition qu’une politique d’accès aux lignes soit non définie sur la table ou la vue sous-jacente.

Les politiques d’accès aux lignes et les vues matérialisées présentent les limitations suivantes :

  • Une vue matérialisée ne peut pas être créée à partir d’une table si une politique d’accès aux lignes est ajoutée à la table sous-jacente.

  • Une politique d’accès aux lignes ne peut pas être ajoutée à une table si une vue matérialisée a été créée à partir de cette table sous-jacente.

Instructions CREATE TABLE

Ce qui suit résume comment les politiques d’accès aux lignes affectent les instructions CREATE TABLE :

CREATE TABLE … CLONE

L’approche suivante permet de protéger les données des utilisateurs avec le privilège SELECT sur la table ou la vue lors de l’accès à un objet cloné :

  • Le clonage d’un objet de politique individuel n’est pas pris en charge.

  • Le clonage d’un schéma entraîne le clonage de toutes les politiques au sein du schéma.

  • Une table clonée correspond aux mêmes politiques que la table source. En d’autres termes, si une politique est définie sur la table de base ou ses colonnes, la politique est attachée à la table clonée ou ses colonnes.

    • Lorsqu’une table est clonée dans le contexte de son clonage de schéma parent, si la table source a une référence à une politique dans le même schéma parent (c’est-à-dire une référence locale), la table clonée aura une référence à la politique clonée.

    • Si la table source fait référence à une politique dans un schéma différent (c’est-à-dire une référence étrangère), la table clonée conserve la référence étrangère.

Pour plus d’informations, voir CREATE <objet> … CLONE.

CREATE TABLE … LIKE

Si une politique d’accès aux lignes est définie sur la table de base, la politique d’accès aux lignes n’est pas définie sur une colonne de la nouvelle table. La nouvelle table est vide.

CREATE TABLE … AS SELECT

Si une politique d’accès aux lignes est définie sur la table de base, la nouvelle table contient les lignes filtrées en fonction de la définition de la politique d’accès aux lignes. La nouvelle table n’a pas de politique d’accès aux lignes définie sur une colonne.

Profil de requête

Au moment de l’exécution de la requête, Snowflake crée une vue dynamique sécurisée.

Lorsque vous utilisez la commande EXPLAIN sur un objet de base de données dans lequel une politique d’accès aux lignes est définie, le résultat de la requête indique qu’une politique d’accès aux lignes est présente. Lorsqu’une politique d’accès aux lignes est définie sur l’objet de base de données, le résultat de la requête EXPLAIN spécifie les valeurs de colonne suivantes :

  • La colonne operation comprend la valeur DynamicSecureView.

  • La colonne object comprend la valeur "<nom_objet> (+ RowAccessPolicy)".

Chaque étape du plan de requête qui nécessite l’appel de la politique d’accès aux lignes a pour conséquence que les colonnes operation et object spécifient les valeurs correspondantes pour cette étape du plan de requête. Si la politique d’accès aux lignes n’a été appelée qu’une seule fois dans la requête, une seule ligne du résultat de la requête EXPLAIN comprend les valeurs DynamicSecureView et "<nom_objet> (+ RowAccessPolicy)" .

Dans le résultat de la commande EXPLAIN et dans l’interface Web du profil de requête, Snowflake ne montre aux utilisateurs aucune information sur la politique d’accès aux lignes (c’est-à-dire le nom de la politique, la signature de la politique, l’expression de la politique) ni les objets auxquels la politique donne accès.

L’exemple suivant montre qu’une politique d’accès aux lignes n’est appelée qu’une seule fois.

EXPLAIN SELECT * FROM my_table;
Copy
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step |   id   | parent |     operation     |           objects              | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
...

| 1     | 2      | 1      | DynamicSecureView | "MY_TABLE (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+

L’exemple suivant indique qu’une politique d’accès aux lignes est appelée deux fois sur la même table :

EXPLAIN SELECT product FROM sales
  WHERE revenue > (SELECT AVG(revenue) FROM sales)
  ORDER BY product;
Copy
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step  |   id   | parent |     operation     |           objects           | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
...
| 1      | 0      | [NULL] | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
...
| 2      | 2      | 1      | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+

Time Travel

Snowflake prend en charge Time Travel sur les tables et les vues avec une politique d’accès aux lignes.

Au moment de l’exécution de la requête, Snowflake évalue les tables de mappage de la politique d’accès aux lignes au moment de la requête ; en d’autres termes, Time Travel n’affecte pas la table de mappage.

Pour plus d’informations, voir Comprendre et utiliser la fonction « Time Travel ».

Réplication

Les politiques d’accès aux lignes et leurs affectations peuvent être répliquées à l’aide de la réplication de bases de données et de groupes de réplication.

Pour la réplication de base de données, l’opération de réplication échoue si l’une des conditions suivantes est vraie :

  • La base de données principale se trouve dans un compte Enterprise (ou supérieur) et contient une politique, mais au moins un des comptes approuvés pour la réplication se trouve sur des éditions inférieures.

  • Une table ou une vue contenue dans la base de données principale comporte une référence pendante à une politique d’accès aux lignes dans une autre base de données.

Le comportement de la référence pendante pour la réplication des bases de données peut être évité lors de la réplication de plusieurs bases de données dans un groupe de réplication.

Note

En cas d’utilisation des actions de basculement et de restauration, le compte Snowflake doit être Business Critical Edition ou supérieur.

Pour plus d’informations, voir Présentation de la réplication et du basculement à travers plusieurs comptes.

Partage de données

Utilisation
  • Si le fournisseur affecte une politique à une table ou à une vue partagée et que les conditions de la politique appellent la fonction CURRENT_ROLE ou CURRENT_USER, ou que les conditions de la politique appellent une UDF sécurisée, Snowflake renvoie une valeur NULL pour la fonction ou l’UDF dans le compte du consommateur.

    La raison en est que le propriétaire des données partagées ne contrôle généralement pas les utilisateurs ou les rôles du compte avec lequel la table ou la vue est partagée. Comme solution de contournement, utilisez la fonction CURRENT_ACCOUNT dans les conditions de la politique.

    En tant que fournisseur, vous pouvez également écrire les conditions de la politique pour appeler la fonction IS_DATABASE_ROLE_IN_SESSION et partager le rôle de la base de données. En tant que consommateur, accordez le rôle de base de données partagée à un rôle de compte. Pour plus de détails, voir Partagez des données protégées par une politique.

Limites
  • Un fournisseur de partage de données ne peut pas créer de politique dans un compte de lecteur.

  • Les consommateurs de partage de données ne peuvent pas appliquer une politique à une table ou une vue partagée. Comme solution de rechange, importez la base de données partagée et créez une vue locale à partir de la table ou de la vue partagée.

  • Les consommateurs de partage de données ne peuvent pas interroger une table ou une vue partagée qui fait référence à deux fournisseurs différents. Par exemple :

    • rap1 est une politique d’accès aux lignes qui protège la table nommée t1, où t1 est dans le partage nommé share1 d’un fournisseur.

    • Les conditions de la politique rap1 font référence à une table de mappage nommée t2, où t2 provient de share2 et d’un fournisseur différent.

    • La requête du consommateur sur t1 échoue.

    • Le fournisseur de t1 peut interroger t1.

  • Fonctions externes :

    Snowflake renvoie une erreur si :

    • La politique affectée à une table ou une vue partagée est mise à jour pour appeler une fonction externe.

    • La politique appelle une fonction externe et vous tentez d’affecter la politique à une table ou une vue partagée.

Gérez les politiques d’accès aux lignes

Choix d’une approche de gestion centralisée, hybride ou décentralisée

Pour gérer efficacement les politiques d’accès aux lignes, il est utile de se demander si votre approche du filtrage des lignes doit suivre une approche de gouvernance centralisée, décentralisée ou hybride.

Le tableau suivant résume certaines des considérations relatives à chacune de ces trois approches.

Action de la politique

Centralisée

Hybride

Décentralisée

Créer des politiques

Responsable de la gouvernance

Responsable de la gouvernance

Équipes individuelles

Appliquer des politiques aux colonnes

Responsable de la gouvernance

Équipes individuelles

Équipes individuelles

Pour des exemples de syntaxe, voir Résumé des commandes, des opérations et des privilèges DDL.

Astuce

En tant que meilleure pratique, Snowflake recommande que votre organisation rassemble toutes les parties prenantes concernées afin de déterminer la meilleure approche de gestion pour implémenter les politiques d’accès aux lignes dans votre environnement.

Privilèges de la politique d’accès aux lignes

Snowflake prend en charge les privilèges de politiques d’accès aux lignes suivants pour déterminer si les utilisateurs peuvent créer, définir et posséder des politiques d’accès aux lignes.

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

Privilège

Utilisation

CREATE

Permet de créer une nouvelle politique d’accès aux lignes dans un schéma.

APPLY

Permet d’exécuter des opérations d’ajout et de destruction pour la politique d’accès aux lignes sur une table ou une vue.

Notez que l’octroi du privilège global APPLY ROW ACCESS POLICY (c’est-à-dire APPLY ROW ACCESS POLICY sur ACCOUNT) permet d’exécuter l’opération DESCRIBE sur des tables et des vues.

Pour des exemples de syntaxe, voir Résumé des commandes, des opérations et des privilèges DDL.

OWNERSHIP

Permet un contrôle total de la politique d’accès aux lignes. Nécessaire pour modifier la plupart des propriétés d’une politique d’accès aux lignes. Un seul rôle peut détenir ce privilège sur un objet spécifique à la fois.

Politique d’accès aux lignes DDL

Snowflake prend en charge les commandes et opérations DDL suivantes pour gérer les politiques d’accès aux lignes.

Résumé des commandes, des opérations et des privilèges DDL

Le tableau suivant résume la relation entre les opérations DDL de politique d’accès aux lignes et leurs privilèges nécessaires.

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

Fonctionnement

Privilège requis

Créer une politique d’accès aux lignes

Un rôle avec le privilège CREATE ROW ACCESS POLICY dans le même schéma.

Modifier la politique d’accès aux lignes

Le rôle avec le privilège OWNERSHIP sur la politique d’accès aux lignes.

Politique d’accès aux lignes Add/Drop

Un rôle doté du privilège APPLY ROW ACCESS POLICY sur le compte ou un rôle doté du privilège OWNERSHIP sur l’objet de base de données et du privilège APPLY sur l’objet de politique d’accès aux lignes.

Détruire une politique d’accès aux lignes

Un des éléments suivants : un rôle doté du privilège OWNERSHIP sur la politique d’accès aux lignes ou . Un rôle doté du privilège OWNERSHIP sur le schéma dans lequel la politique d’accès aux lignes existe.

Afficher les politiques d’accès aux lignes

Un des éléments suivants : . Un rôle doté du privilège APPLY ROW ACCESS POLICY, ou . Le privilège OWNERSHIP de la politique d’accès aux lignes, ou . Le privilège APPLY de la politique d’accès aux lignes.

Décrire la politique d’accès aux lignes

Un des éléments suivants : Un rôle doté du privilège APPLY ROW ACCESS POLICY, ou . Le privilège OWNERSHIP de la politique d’accès aux lignes, ou . Le privilège APPLY de la politique d’accès aux lignes.

Snowflake prend en charge différentes autorisations pour créer et définir une politique d’accès aux lignes sur un objet.

  1. Pour une approche de gestion centralisée des politiques d’accès aux lignes, dans laquelle le rôle personnalisé rap_admin crée et définit des politiques d’accès aux lignes sur tous les objets, les autorisations suivantes sont nécessaires :

    use role securityadmin;
    grant create row access policy on schema <db_name.schema_name> to role rap_admin;
    grant apply row access policy on account to role rap_admin;
    
    Copy
  2. Dans une approche de gestion hybride, un rôle unique dispose du privilège CREATE ROW ACCESS POLICY pour assurer la création cohérente de politiques afin d’optimiser les performances des requêtes, et des équipes ou rôles individuels disposent du privilège APPLY pour une politique d’accès aux lignes spécifique afin de protéger leurs tables et vues.

    Par exemple, le rôle personnalisé finance_role peut se voir accorder l’autorisation d’ajouter la politique d’accès aux lignes rap_finance sur les tables et les vues qu’il possède :

    use role securityadmin;
    grant create row access policy on schema <db_name.schema_name> to role rap_admin;
    grant apply on row access policy rap_finance to role finance_role;
    
    Copy

Contrôlez les politiques d’accès aux lignes avec SQL

Vous pouvez contrôler l’utilisation de la politique d’accès aux lignes par le biais de deux vues différentes Account Usage et d’une table Information Schema.

Il peut être utile de penser à deux approches générales pour déterminer comment suivre l’utilisation de la politique d’accès aux lignes :

Découvrez les politiques d’accès aux lignes

Vous pouvez utiliser la vue ROW_ACCESS_POLICIES dans le schéma Account Usage de la base de données partagée SNOWFLAKE. Cette vue est un catalogue de toutes les politiques d’accès aux lignes de votre compte Snowflake. Par exemple :

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ROW_ACCESS_POLICIES
ORDER BY POLICY_NAME;
Copy

Identifier les affectations

Snowflake prend en charge différentes options pour identifier les affectations de politiques d’accès aux lignes, selon que la requête doit cibler le compte ou une base de données spécifique.

  • Requête au niveau du compte :

    Utilisez la vue Account Usage POLICY_REFERENCES pour déterminer toutes les tables qui ont une politique d’accès aux lignes. Par exemple :

    SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
    ORDER BY POLICY_NAME, REF_COLUMN_NAME;
    
    Copy
  • Requête au niveau de la base de données :

    Chaque base de données Snowflake comprend un Schéma d’information de Snowflake. Utilisez la fonction de table Information Schema POLICY_REFERENCES pour déterminer tous les objets associés à une politique d’accès aux lignes spécifique :

    SELECT *
    FROM TABLE(
      my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
        POLICY_NAME => 'rap_t1'
      )
    );
    
    Copy

Contrôlez les politiques d’accès aux lignes avec Snowsight

Vous pouvez utiliser la zone Snowsight Data » Governance pour surveiller l’utilisation des politiques et des balises avec les tables, les vues et les colonnes, et établir des rapports à ce sujet. Il existe deux interfaces différentes : Dashboard et Tagged Objects.

Lors de l’utilisation de l’interface Dashboard et de l’interface Tagged Objects, il convient de tenir compte des détails suivants.

  • Les interfaces Dashboard et Tagged Objects nécessitent un entrepôt en service.

  • Snowsight met à jour le Dashboard toutes les 12 heures.

  • Le temps de latence de l’information Tagged Objects peut aller jusqu’à deux heures et les retours jusqu’à 1 000 objets.

Accès à la zone de gouvernance dans Snowsight

Pour accéder à la zone Governance , votre compte Snowflake doit être Enterprise Edition ou supérieur. En outre, vous devez effectuer l’une des opérations suivantes :

  • Utilisez le rôle ACCOUNTADMIN.

  • Utilisez un rôle de compte auquel sont attribués les rôles de base de données GOVERNANCE_VIEWER et OBJECT_VIEWER.

    Pour déterminer si votre rôle de compte s’est vu attribuer ces rôles de base de données, utilisez une commande SHOW GRANTS :

    SHOW GRANTS TO ROLE data_engineer;
    
    Copy

    Pour plus de détails sur ces rôles de base de données, consultez Rôles des bases de données SNOWFLAKE.

Tableau de bord

En tant qu’administrateur de données, vous pouvez utiliser l’interface Dashboard pour surveiller l’utilisation des balises et des politiques de la manière suivante.

  • Couverture : spécifie le nombre et le pourcentage en fonction de la présence d’une politique ou d’une balise dans une table, une vue ou une colonne.

  • Prévalence : liste et compte les politiques et les balises les plus fréquemment utilisées.

La couverture et la prévalence donnent un aperçu de la qualité de la protection et du balisage des données.

Lorsque vous sélectionnez un nombre, un pourcentage, un nom de politique ou un nom de balise, l’interface Tagged Objects s’ouvre. L’interface Tagged Objects met à jour les filtres automatiquement en fonction de votre sélection dans l’interface Dashboard.

Les informations de surveillance constituent une alternative ou un complément à l’exécution d’opérations complexes et exigeantes en requêtes sur plusieurs vues Account Usage.

Ces vues peuvent inclure, sans s’y limiter, les vues COLUMNS, POLICY_REFERENCES, TABLES, TAG_REFERENCES, et VIEWS.

Objets balisés

En tant qu’administrateur de données, vous pouvez utiliser cette table pour associer rapidement la couverture et la prévalence dans Dashboard à une liste de tables, de vues ou de colonnes spécifiques. Vous pouvez également filtrer manuellement les résultats de la table, comme suit.

  • Choisissez Tables ou Columns.

  • Pour les balises, vous pouvez filtrer avec les balises, sans les balises ou par une balise spécifique.

  • Pour les politiques, vous pouvez filtrer avec les politiques, sans les politiques ou par une politique spécifique.

Lorsque vous sélectionnez une ligne dans la table, l’onglet Table Details ou Columns de Data » Databases s’ouvre. Vous pouvez modifier les attributions des balises et des politiques si nécessaire.

Auditez les politiques d’accès aux lignes

Snowflake prend en charge les approches suivantes pour faciliter les opérations d’audit et de gouvernance des politiques d’accès aux lignes.

  • Utilisez SHOW ROW ACCESS POLICIES pour produire une liste des politiques d’accès aux lignes qui n’ont pas été détruites de votre compte.

  • Les administrateurs de politiques d’accès aux lignes (c’est-à-dire les utilisateurs disposant du privilège de politique d’accès aux lignes OWNERSHIP) peuvent utiliser Time Travel ou les flux pour capturer des données historiques sur les tables de mappage référencées dans leurs politiques d’accès aux lignes.

  • Pour déterminer les données auxquelles un utilisateur donné peut accéder, l’administrateur de la politique d’accès aux lignes peut assumer le rôle de l’utilisateur et exécuter une requête.

    • Snowflake prend en charge la définition d’une expression de politique d’accès aux lignes avec une logique personnalisée pour prendre en charge ce comportement dans la commande CREATE ROW ACCESS POLICY .

    • Snowflake ne dispose pas actuellement d’un mécanisme par défaut (par exemple, un système dédié ou une fonction contextuelle) pour prendre en charge cette opération.

  • Si une politique d’accès aux lignes donnée utilise des tables de mappage pour déterminer quels rôles et quelles populations d’utilisateurs peuvent accéder aux données des lignes, le propriétaire de la politique d’accès aux lignes peut interroger les tables de mappage pour déterminer l’accès autorisé des utilisateurs à la demande.

  • Snowflake capture et enregistre les informations des messages d’erreur liés aux politiques d’accès aux lignes dans la vue Account Usage Vue QUERY_HISTORY . Si une erreur se produit dans une requête, Snowflake enregistre le premier message d’erreur qui survient pendant l’évaluation de la requête. Pour plus d’informations sur les messages d’erreur des politiques d’accès aux lignes, voir Dépannage des politiques d’accès aux lignes.

  • Pour déterminer les données auxquelles un utilisateur donné a accédé dans le passé en ce qui concerne les politiques d’accès aux lignes sur les objets de la base de données, utilisez Time Travel en combinaison avec la vue Account Usage ROW_ACCESS_POLICIES et la fonction de table d’Information Schema POLICY_REFERENCES.

    • Si la politique et les tables de mappage, le cas échéant, n’ont pas été modifiées, l’administrateur de la politique d’accès aux lignes peut assumer le rôle de l’utilisateur et exécuter une requête Time Travel. Les valeurs des paramètres de session pertinents, tels que CURRENT_ROLE, sont disponibles dans le résultat de la requête.

    • Si la politique ou les tables de mappage ont changé, l’administrateur de la politique d’accès aux lignes doit exécuter une requête Time Travel sur la table de mappage et reconstruire la politique d’accès aux lignes qui existait au moment de l’incident spécifié. Après ces étapes, l’administrateur de la politique d’accès aux lignes peut commencer à interroger les données et procéder à leur analyse.

Dépannez des politiques d’accès aux lignes

Les comportements et messages d’erreur suivants s’appliquent aux politiques d’accès aux lignes.

Comportement

Message d’erreur

Action de dépannage

Impossible de définir une politique d’accès aux lignes (vue matérialisée).

La politique d’accès aux lignes ne peut pas être attachée à une vue matérialisée.

Vérifiez qu’une politique d’accès aux lignes peut être définie sur la vue matérialisée. Voir Vues matérialisées (dans cette rubrique).

Impossible de créer une politique d’accès aux lignes (booléen).

003551=SQL compilation error: Le type de retour de la politique d’accès aux lignes « {0} » n’est pas BOOLEAN.

Une définition de politique d’accès aux lignes doit avoir RETURNS BOOLEAN. Réécrivez la politique d’accès aux lignes comme indiqué dans CREATE ROW ACCESS POLICY.

Impossible de créer une politique d’accès aux lignes (Base de données).

Cette session ne dispose pas d’une base de données actuelle. Appelez “USE DATABASE”, ou utilisez un nom qualifié.

Étant donné qu’une politique d’accès aux lignes est un objet de niveau schéma, définissez une base de données et un schéma pour la session en cours ou utilisez le nom entièrement qualifié dans la commande CREATE ROW ACCESS POLICY. Pour plus d’informations, voir Résolution de nom d’objet.

Impossible de créer une politique d’accès aux lignes (l’objet existe).

Erreur de compilation SQL : l’objet “<nom>” existe déjà.

Puisqu’il existe déjà une politique d’accès aux lignes dans le schéma avec le nom indiqué, recréez la politique d’accès aux lignes avec une valeur différente de name.

Impossible de créer une politique d’accès aux lignes (propriété du schéma).

Erreur de contrôle d’accès SQL : privilèges insuffisants pour effectuer des opérations sur le schéma “S1”

Vérifiez les privilèges pour créer une politique d’accès aux lignes dans Résumé de commandes, opérations et privilèges DDL (dans cette rubrique).

Impossible de créer une politique d’accès aux lignes (utilisation des schémas).

Erreur de compilation SQL : le schéma “<nom_schéma>” n’existe pas ou n’est pas autorisé.

Vérifiez que le schéma spécifié existe et que les privilèges permettant de créer une politique d’accès aux lignes dans Résumé des commandes, opérations et privilèges DDL (dans cette rubrique).

Impossible de décrire une politique d’accès aux lignes (utilisation uniquement).

Erreur de compilation SQL : la politique d’accès à la ligne “RLS_AUTHZ_DB.S_B.P1” n’existe pas ou n’est pas autorisée.

Il ne suffit pas de disposer du privilège USAGE sur la base de données et le schéma parents dans lesquels la politique d’accès aux lignes existe pour exécuter une opération DESCRIBE sur la politique d’accès aux lignes. Vérifiez l’existence de la politique d’accès aux lignes et les privilèges permettant de décrire une politique d’accès aux lignes dans Résumé des commandes, opérations et privilèges DDL (dans cette rubrique).

Impossible de détruire une politique d’accès aux lignes. (Maintenance).

Erreur de compilation SQL : la politique d’accès à la ligne “RLS_AUTHZ_DB.S_B.P1” n’existe pas ou n’est pas autorisée.

Vérifiez l’existence de la politique d’accès aux lignes spécifiée et les privilèges permettant de détruire une politique d’accès aux lignes dans Résumé des commandes, opérations et privilèges DDL (dans cette rubrique).

Impossible d’exécuter UNDROP sur une politique d’accès aux lignes. (Maintenance)

Fonctionnalité non prise en charge “UNDROP non prise en charge pour les objets de type ROW_ACCESS_POLICY”.

Pour rétablir une politique d’accès aux lignes, exécutez une commande CREATE ROW ACCESS POLICY, puis ajoutez la politique d’accès aux lignes à un objet de base de données à l’aide d’une commande ALTER TABLE ou ALTER VIEW, comme indiqué dans ALTER TABLE ou ALTER VIEW.

Impossible de mettre à jour une politique d’accès aux lignes (Nom/Opération).

Erreur de compilation SQL : l’objet trouvé est de type “ROW_ACCESS_POLICY”, type “MASKING_POLICY” non spécifié.

Vérifiez la requête pour contrôler le nom de l’objet et l’opération prévue sur l’objet. . . Par exemple, Snowflake ne prend pas en charge ALTER ROW ACCESS POLICY <nom>;. . . Utilisez plutôt une commande CREATE OR REPLACE ROW ACCESS POLICY pour mettre à jour une politique d’accès aux lignes. Pour plus d’informations sur les opérations de politique d’accès aux lignes, voir Résumé des commandes, opérations et privilèges DDL (dans ce chapitre).

Impossible d’utiliser les politiques d’accès aux lignes avec une fonctionnalité ou un service Snowflake (fonctionnalité non prise en charge).

Fonctionnalité non prise en charge “CREATE ON OBJECTS ENFORCED BY ROW ACCESS POLICY”.

Certaines fonctionnalités et certains services Snowflake ne prennent pas en charge les politiques d’accès aux lignes. Pour plus d’informations, consultez les sections Limites et Utilisation des politiques d’accès aux lignes avec les objets et fonctionnalités Snowflake de ce chapitre.

Impossible de mettre à jour une politique d’accès aux lignes (jeton non pris en charge).

Fonctionnalité non prise en charge “TOK_ROW_ACCESS_POLICY”.

TOK fait référence à un jeton, qui peut être renvoyé si une requête n’est pas prise en charge et/ou est imprécise ; le compilateur SQL de Snowflake ne sait pas comment traiter la requête donnée. . Par exemple alter row access policy p1_test set comment = 'test policy 1';. Dans cet exemple, la commande ALTER ne peut pas être utilisée directement sur l’objet de la politique ; utilisez plutôt une commande ALTER TABLE ou ALTER VIEW comme indiqué dans Résumé des commandes, opérations et privilèges DDL (dans cette rubrique).

Chapitres suivants :