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

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.

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.

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 :

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

• Politique d’accès aux lignes DDL

• Utilisez les politiques d’accès aux lignes

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()
;

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 :

• Tables externes (dans cette rubrique)

• Utilisez les politiques d’accès aux lignes

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 à :

• Fonction mémoïsable (dans l’aperçu de l’UDF SQL scalaire).

• Utilisation d’une fonction mémoïsable dans une politique (dans la rubrique Utilisation des politiques d’accès aux lignes).

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.

Limitations¶

• 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).

• Soyez prudent(e) lors de la création du script de configuration d’une Snowflake Native App lorsque la politique d’accès aux lignes existe dans un schéma versionné. Pour des informations détaillées, voir Considérations sur les schémas versionnés.

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. Si la politique contient une consultation de table de mappage, créez une table de mappage centralisée et stockez la table de mappage dans la même base de données que la table protégée. Ceci est particulièrement important si la politique appelle la fonction IS_DATABASE_ROLE_IN_SESSION. Pour des informations détaillées, voir les notes sur l’utilisation de la fonction.

Pour ces cas d’utilisation, Snowflake recommande d’écrire les conditions de la politique pour appeler la fonction IS_ROLE_IN_SESSION ou IS_DATABASE_ROLE_IN_SESSION selon que vous souhaitez spécifier un rôle de compte ou un rôle de base de données. Pour des exemples, voir :

• section Exemples dans la fonction IS_ROLE_IN_SESSION.

• IS_DATABASE_ROLE_IN_SESSION

• Partagez des données protégées par une politique

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.

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 Limitations.

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 Limitations.

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.

Limitations:

• 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.

Snowflake Native App Framework¶

Pour des informations détaillées sur l’utilisation de politiques d’accès aux lignes avec une Snowflake Native App, voir :

• Restrictions sur le partage du contenu de données contenant des politiques.

• Définir des politiques sur les vues proxy.

• Fonctions contextuelles bloquées.

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.

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

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.

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.

• CREATE ROW ACCESS POLICY

• ALTER ROW ACCESS POLICY

• DROP ROW ACCESS POLICY

• SHOW ROW ACCESS POLICIES

• DESCRIBE ROW ACCESS POLICY

• ALTER TABLE, ALTER EXTERNAL TABLE, et ALTER VIEW (pour ajouter/détruire une politique sur une table ou une vue)

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.

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

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

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 directement attribués les rôles de base de données GOVERNANCE_VIEWER et OBJECT_VIEWER.

  Vous devez utiliser un rôle de compte avec ces attributions de rôle de base de données. Actuellement, Snowsight n’évalue pas les hiérarchies de rôles et les rôles de base de données définis par l’utilisateur qui ont accès aux tables, aux vues, aux politiques d’accès aux données et aux balises.

  Pour déterminer si votre rôle de compte bénéficie de ces deux rôles de base de données, utilisez une commande SHOW GRANTS :

  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
  | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  

  
  

  Si votre rôle de compte ne bénéficie pas de l’un ou de l’autre de ces rôles de base de données, ou n’en a aucun des deux, utilisez la commande GRANT DATABASE ROLE et exécutez de nouveau la commande SHOW GRANTS pour confirmer les attributions :

  USE ROLE ACCOUNTADMIN;
  GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
  GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
  SHOW GRANTS LIKE '%VIEWER%' 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.