Comprendre la sécurité au niveau des lignes

Cette rubrique présente une introduction à la sécurité au niveau des lignes et aux politiques d’accès aux 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 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 est ajoutée à une table à l’aide d’une instruction ALTER TABLE et à une vue à l’aide d’une instruction ALTER VIEW .

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.

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 Utilisation de la sécurité au niveau des lignes.

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.

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

  • Vues matérialisées :

    • 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 à cette table.

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

  • Flux :

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

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 de la sécurité au niveau des 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 :

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.

Tables externes

Vous pouvez appliquer la politique d’accès aux lignes à la colonne VALUE External Table en exécutant une instruction ALTER EXTERNAL 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 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.

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

    Si la réplication utilise Failover ou Failback, 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.

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 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 de la sécurité au niveau des 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 de la sécurité au niveau des 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 la sécurité au niveau des lignes dans votre environnement.

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

Snowflake prend en charge les privilèges de sécurité au niveau des 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.

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 sécurité au niveau des 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 schéma ou un rôle doté du privilège OWNERSHIP sur l’objet 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 :