CREATE ROW ACCESS POLICY¶

Crée une nouvelle politique d’accès aux lignes dans le schéma actuel/spécifié ou remplace une politique d’accès aux lignes existante.

Après avoir créé une politique d’accès aux lignes, ajoutez la politique à une table à l’aide d’une commande ALTER TABLE ou à une vue à l’aide d’une commande ALTER VIEW.

Voir aussi :: Politique d’accès aux lignes DDL

Syntaxe¶

Snowflake prend en charge la syntaxe suivante pour créer une politique d’accès aux lignes.

CREATE [ OR REPLACE ] ROW ACCESS POLICY [ IF NOT EXISTS ] <name> AS
( <arg_name> <arg_type> [ , ... ] ) RETURNS BOOLEAN -> <body>
[ COMMENT = '<string_literal>' ]

Copy

Paramètres requis¶

name

Identificateur de la politique d’accès à la ligne ; doit être unique pour votre schéma.

La valeur de l’identificateur doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que toute la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. « Mon objet »). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus de détails, voir Exigences relatives à l’identificateur

AS ( <arg_name> <arg_type> [ , ... ] )

La signature de la politique d’accès aux lignes.

Une signature spécifie un ensemble d’attributs qui doivent être pris en compte pour déterminer si la ligne est accessible. Les valeurs de l’attribut proviennent de l’objet de la base de données (par exemple, une table ou une vue) qui doit être protégé par la politique d’accès aux lignes.

RETURNS BOOLEAN

Une stratégie d’accès aux lignes doit être évaluée comme vraie ou fausse. Un utilisateur qui interroge une table protégée par une politique d’accès aux lignes voit les lignes dans la sortie en fonction de la façon dont le body est écrit.

body

Expression SQL qui opère sur les valeurs d’argument dans la signature pour déterminer les lignes à renvoyer pour une requête sur une table protégée par une politique d’accès aux lignes.

body peut être n’importe quelle expression SQL à valeur booléenne. Snowflake prend en charge les expressions qui appellent Vue d’ensemble des fonctions définies par l’utilisateur, Écriture de fonctions externes et les expressions qui utilisent des sous-requêtes.

Paramètres facultatifs¶

COMMENT = 'string_literal'

Spécifie un commentaire pour la politique d’accès aux lignes.

Par défaut : aucune valeur

Exigences en matière de contrôle d’accès¶

Un rôle utilisé pour exécuter cette commande SQL doit avoir les privilèges suivants définis au minimum ainsi :

Privilège	Objet	Remarques
CREATE ROW ACCESS POLICY	Schéma

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.

Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.

Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.

Pour plus de détails sur la DDL de politique de masquage et les privilèges, voir Gestion de la sécurité au niveau des colonnes.

Notes sur l’utilisation¶

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.
Si 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, la politique d’accès aux lignes est évaluée en premier.

Pour plus d’informations sur les politiques d’accès aux lignes pendant l’exécution d’une requête, voir Présentation des politiques 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.
Vous ne pouvez pas modifier la signature de la politique (c’est-à-dire le nom de l’argument ou le type de données d’entrée/sortie) en utilisant CREATE OR REPLACE ROW ACCESS POLICY si la politique est attachée à une table ou à une vue, ou en utilisant ALTER ROW ACCESS POLICY. Si vous devez modifier la signature, exécutez une instruction DROP ROW ACCESS POLICY sur la politique et créez une nouvelle politique d’accès aux lignes.
Si la politique body contient une consultation de table de mappage, créez une table de mappage centralisée et stockez-la dans la même base de données que la table protégée. Ceci est particulièrement important si body appelle la fonction IS_DATABASE_ROLE_IN_SESSION. Pour plus de détails, voir les notes sur l’utilisation de la fonction.
Un fournisseur de partage de données ne peut pas créer une politique d’accès aux lignes dans un compte de lecteur.
Concernant les métadonnées :

Attention

Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.
Les instructions CREATE OR REPLACE <objet> sont atomiques. En d’autres termes, lorsqu’un objet est remplacé, l’ancien objet est supprimé et le nouvel objet est créé dans une seule transaction.

Exemples¶

Ces exemples utilisent la fonction de contexte CURRENT_ROLE. Si l’activation des rôles et la hiérarchie des rôles sont nécessaires dans les conditions de la politique, utilisez IS_ROLE_IN_SESSION.

La politique d’accès aux lignes suivante permet aux utilisateurs dont CURRENT_ROLE est le rôle personnalisé it_admin de voir les lignes qui contiennent le numéro de l’ID de l’employé (c’est-à-dire empl_id) dans le résultat de la requête.

create or replace row access policy rap_it as (empl_id varchar) returns boolean ->
  case
      when 'it_admin' = current_role() then true
      else false
  end
;

Copy

La politique d’accès aux lignes suivante permet aux utilisateurs de visualiser les lignes du résultat de la requête si l’une des deux conditions suivantes est vraie :

Le rôle actuel est le rôle personnalisé sales_executive_role . Appelez la fonction CURRENT_ROLE pour déterminer le rôle actuel.
Le rôle actuel est le rôle personnalisé sales_manager et la requête spécifie un sales_region qui correspond à la table de mappage salesmanageregions .

use role securityadmin;

create or replace row access policy rap_sales_manager_regions_1 as (sales_region varchar) returns boolean ->
  'sales_executive_role' = current_role()
      or exists (
            select 1 from salesmanagerregions
              where sales_manager = current_role()
                and region = sales_region
          )
;
Copy
Où :

rap_sales_manager_regions_1
Le nom de la politique d’accès aux lignes.

as (sales_region varchar)
La signature de la politique d’accès aux lignes.

Une signature spécifie un ensemble d’attributs qui doivent être pris en compte pour déterminer si la ligne est accessible. Les valeurs des attributs proviennent de la table à protéger par la politique d’accès aux lignes.

returns boolean ->
Spécifie l’application de la politique d’accès aux lignes.

Notez que les <expression> de la politique d’accès aux lignes suivent immédiatement la flèche de droite (c’est-à-dire ->).

L’expression peut être n’importe quelle expression SQL à valeur booléenne. Snowflake prend en charge les expressions qui appellent des UDFs, des fonctions externes et des expressions qui utilisent des sous-requêtes.

'sales_executive_role' = current_role()
La première condition de l’expression de la politique d’accès aux lignes qui permet aux utilisateurs ayant le rôle personnalisé sales_executive_role de visualiser les données.

or exists (select 1 from salesmanagerregions where sales_manager = current_role() and region = sales_region)
La deuxième condition de l’expression de la politique d’accès aux lignes qui utilise une sous-requête.

La sous-requête exige que le rôle personnalisé CURRENT_ROLE soit le rôle personnalisé sales_manager et que la requête exécutée sur les données spécifie une région répertoriée dans la table de mappage salesmanagerregions .

La politique d’accès aux lignes suivante spécifie deux attributs dans la signature de la politique :

create or replace row access policy rap_test2 as (n number, v varchar)
  returns boolean -> true;
Copy
Où :

rap_test2
Le nom de la politique d’accès aux lignes.

(n number, v varchar)
La signature de la politique d’accès aux lignes.

Une signature spécifie un ensemble d’attributs qui doivent être pris en compte pour déterminer si la ligne est accessible. Les valeurs des attributs proviennent de la table à protéger par la politique d’accès aux lignes.

returns boolean -> true
Détermine l’application de la politique d’accès aux lignes.

La valeur renvoyée détermine si l’utilisateur a accès à une ligne donnée de l’objet de base de données auquel la politique d’accès aux lignes est ajoutée.

Pour d’autres exemples, voir Utilisez les politiques d’accès aux lignes.