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

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.

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.

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.

  • Les autorisations futures ne peuvent pas être utilisées avec les politiques d’accès aux lignes. Comme solution de rechange, accordez le privilège APPLY ROW ACCESS POLICY à un rôle pour définir des politiques d’accès aux lignes.

  • Service d’optimisation de la recherche. Les objets de base de données protégés par une politique d’accès aux lignes ne peuvent pas être utilisés avec les services d’optimisation des recherches. Pour plus d’informations, voir Dépannage des politiques d’accès aux lignes (dans ce chapitre).

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

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.

  • IS_ROLE_IN_SESSION ne peut pas être utilisé avec des politiques d’accès aux lignes qui contiennent des tables de mappage. Cette fonction peut être utilisée avec des politiques d’accès aux lignes qui ne contiennent pas de tables de mappage.

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

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

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

Pour obtenir une liste des objets de la base de données avec des politiques d’accès aux lignes, exécutez l’instruction suivante.

select *
from table(
  information_schema.policy_references(
    policy_name=>'<policy_name>'
  )
);

Pour plus d’informations, voir :

Appliquer 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;

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

Politiques de masquage de sécurité au niveau des colonnes

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 de masquage, soit dans une signature de politique d’accès aux lignes. En d’autres termes, la même colonne ne peut pas être spécifiée à la fois dans une signature de politique de masquage et dans une signature de politique d’accès aux lignes.

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

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.

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 ou d’une vue si une politique d’accès aux lignes est ajoutée à la table ou la vue sous-jacente.

  • Une politique d’accès aux lignes ne peut pas être ajoutée à une table ou une vue si une vue matérialisée a été créée à partir de la table ou de la vue 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

Si une politique d’accès aux lignes est définie sur la table de base, la politique d’accès aux lignes sera attachée à la table clonée.

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;

+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
|  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;

+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
|  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 objets protégés par une politique peuvent être répliqués s’ils se trouvent dans la même base de données que la politique.

Les politiques d’accès aux lignes individuelles peuvent être répliqué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 fait référence à une politique d’accès aux lignes dans une autre base de données.

    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 Réplication de base de données et basculement/restauration automatique.

Partage de données

Snowflake permet aux fournisseurs et aux consommateurs de partage de données d’ajouter des politiques d’accès aux lignes aux objets de la base de données.

Les fournisseurs de partage de données doivent utiliser des fonctions contextuelles (par exemple, INVOKER_SHARE) dans leurs politiques d’accès aux lignes pour déterminer la population d’utilisateurs autorisés. Si la politique d’accès aux lignes fait référence à une fonction externe, la table ou la vue ne peut pas être partagée.

Les consommateurs de partage de données ne peuvent pas appliquer une politique d’accès aux lignes à une base de données ou à une table partagée. Comme solution de rechange, importez la base de données ou la table partagée et appliquez la politique d’accès aux lignes à une vue locale sur cette base de données ou cette table partagée.

Note

Un fournisseur de partage de données ne peut pas créer une politique d’accès aux lignes dans un compte de lecteur.

Audit des 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.

  • Vues :

    • Interrogez les Vue POLICY_REFERENCES pour connaître les associations de politiques. Notez que cette vue ne renvoie des informations sur les politiques d’accès aux lignes que si votre compte est activé et utilise des politiques d’accès aux lignes.

    • Interrogez Vue ROW_ACCESS_POLICIES pour obtenir une liste de toutes les politiques d’accès aux lignes créées dans 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 les vues Account Usage et Information Schema.

    • 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épannage 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 nom.

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

Gestion des politiques d’accès aux lignes

Choisir 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

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.

Note

Les politiques d’accès aux lignes sont des objets de niveau schéma.

Effectuer des opérations sur une politique d’accès aux lignes nécessite é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

Active les opérations d’ajout et de destruction pour la politique d’accès aux lignes sur une table ou une vue et l’exécution de l’opération DESCRIBE sur des tables ou des vues.

OWNERSHIP

Transfère la propriété d’une politique d’accès aux lignes, qui accorde un contrôle complet 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.

DDL De politique d’accès aux lignes

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, opérations et 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.

Fonctionnement

Privilège requis

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

Un rôle avec le privilège USAGE sur la base de données parente et un schéma 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.

Ajouter/détruire une politique d’accès aux lignes

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

Le rôle avec le privilège OWNERSHIP sur la politique d’accès aux lignes ou un rôle avec le privilège APPLY sur la politique d’accès aux lignes ou un rôle avec le privilège global APPLY ROW ACCESS POLICY.

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

Un rôle avec le privilège OWNERSHIP sur le schéma.

Chapitres suivants :