Politiques de projection¶

Utilisation des colonnes¶

Snowflake suit l’utilisation des colonnes. Les références indirectes à une colonne telles que la définition d’une vue, une UDF (dans ce chapitre) et une expression de table commune ont un impact sur la projection de la colonne lorsqu’une politique de projection est définie sur une colonne.

Lorsqu’une politique de projection est définie sur la colonne et que celle-ci ne peut pas être projetée, la colonne :

• N’est pas incluse dans la sortie du résultat d’une requête.

• Ne peut pas être insérée dans une autre table.

• Ne peut pas être un argument d’une fonction externe ou d’une procédure stockée.

Limitations¶

UDFs:

Pour les limitations concernant les fonctions définies par l’utilisateur (UDFs), voir Fonctions définies par l’utilisateur (UDFs) (dans ce chapitre).

Politique:

Une politique de projection ne peut pas être appliquée aux éléments suivants :

• Une balise, et cette balise ne peut pas être affectée à une table ou à une colonne (c’est-à-dire des « politiques de projection basées sur les balises »).

• Une colonne virtuelle ou la colonne VALUE d’une table externe.

  Pour contourner le problème, créez une vue et affectez une politique de projection à chaque colonne qui ne doit pas être projetée.

• La value_column dans une construction PIVOT. Pour des informations détaillées à ce sujet, voir UNPIVOT (dans ce chapitre).

Une politique de projection body ne peut pas référencer une colonne protégée par une politique de masquage ou une table protégée par une politique d’accès aux lignes. Pour des informations détaillées supplémentaires, voir Politiques de masquage et d’accès aux lignes (dans ce chapitre).

Considérations¶

Utilisez des politiques de projection lorsque le cas d’utilisation nécessite l’interrogation d’une colonne sensible sans exposer directement la valeur de la colonne à un analyste ou à un rôle similaire. La valeur d’une colonne soumise à des contraintes de projection peut être analysée avec une plus grande souplesse qu’une valeur masquée ou tokenisée. Toutefois, avant de définir une politique de projection sur une colonne, il convient de tenir compte des points suivants :

• Une politique de projection n’empêche pas le ciblage d’un individu.

  Par exemple, un utilisateur peut filtrer les lignes pour lesquelles la colonne name correspond à un individu particulier, même si la colonne est soumise à des contraintes de projection. Cependant, l’utilisateur ne peut pas exécuter d’instruction SELECT pour afficher les noms des individus de la table.

• Lorsqu’une colonne soumise à des contraintes de projection est la clé de jointure d’une requête qui combine des données de la table protégée avec des données d’une table non protégée, rien n’empêche l’utilisateur de projeter des valeurs de la colonne dans la table non protégée. Par conséquent, si une valeur de la table non protégée correspond à une valeur de la colonne protégée, l’utilisateur peut obtenir cette valeur en la projetant à partir de la table non protégée.

  Par exemple, supposons qu’une politique de projection ait été affectée à la colonne email de la table t_protected. Un utilisateur peut tout de même déterminer les valeurs de la colonne t_protected.email en exécutant :

  SELECT t_unprotected.email
    FROM t_unprotected JOIN t_protected ON t_unprotected.email = t_protected.email;
  

  Copy

• Une contrainte de projection ne garantit pas qu’un acteur malveillant ne puisse pas utiliser des requêtes délibérées pour tirer des données potentiellement sensibles d’une colonne soumise à des contraintes de projection. Les politiques de projection conviennent le mieux aux partenaires et aux clients avec lesquels vous avez déjà un certain niveau de confiance. En outre, les fournisseurs doivent être vigilants quant à d’éventuelles utilisations abusives de leurs données (par ex., en examinant l’historique d’accès à leurs annonces).

Exemples de politiques¶

Les politiques de projection les plus simples appellent directement la fonction PROJECTION_CONSTRAINT :

Autorisation de la projection d’une colonne

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
PROJECTION_CONSTRAINT(ALLOW => true)

Copy

Prévention de la projection d’une colonne

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
PROJECTION_CONSTRAINT(ALLOW => false)

Copy

Des expressions SQL plus complexes peuvent être écrites pour appeler la fonction PROJECTION_CONSTRAINT. L’expression peut utiliser Fonctions d’expressions conditionnelles et Fonctions contextuelles pour introduire une logique permettant à certains utilisateurs ayant un rôle particulier de projeter une colonne et empêchant tous les autres utilisateurs de projeter une colonne.

Par exemple, utilisez une expression CASE pour n’autoriser que les utilisateurs ayant le rôle personnalisé analyst à projeter une colonne :

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN CURRENT_ROLE() = 'ANALYST'
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Pour les cas d’utilisation de partage de données, le fournisseur peut écrire une politique de projection pour contraindre la projection de colonnes pour tous les comptes de consommateurs via la fonction de contexte CURRENT_ACCOUNT, ou pour restreindre sélectivement la projection de colonnes dans des partages spécifiques via la fonction de contexte INVOKER_SHARE. Par exemple :

Restriction de tous les comptes de consommateurs

Dans cet exemple, provider.account est l”identificateur du compte au format de nom de compte :

CREATE OR REPLACE PROJECTION POLICY restrict_consumer_accounts
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN CURRENT_ACCOUNT() = 'provider.account'
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Restriction à des partages spécifiques

Prenons l’exemple d’un compte de fournisseur de partage de données qui a une politique de projection définie sur une colonne d’une vue sécurisée. Il existe deux partages différents (SHARE1 et SHARE2) qui peuvent accéder à la vue sécurisée pour prendre en charge deux consommateurs de partages de données différents.

Si un utilisateur du compte de consommateur de partage de données tente de projeter la colonne par l’intermédiaire de l’un ou l’autre partage, il peut projeter la colonne, sinon la colonne ne peut pas être projetée :

CREATE OR REPLACE PROJECTION POLICY projection_share
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN INVOKER_SHARE() IN ('SHARE1', 'SHARE2')
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Remplacement d’une politique de projection¶

La méthode recommandée pour remplacer une politique de projection consiste à utiliser le paramètre FORCE pour détacher la politique de projection existante et affecter la nouvelle en une seule commande. Cela vous permet de remplacer atomiquement l’ancienne politique, sans laisser de faille de protection.

Par exemple, pour affecter une nouvelle politique de projection à une colonne déjà soumise à des contraintes de projection :

ALTER TABLE finance.accounting.customers
  MODIFY COLUMN account_number
  SET PROJECTION POLICY proj_policy2 FORCE;

Vous pouvez également détacher la politique de projection d’une colonne dans une instruction (… UNSET PROJECTION POLICY), puis définir une nouvelle politique sur la colonne dans une autre instruction (… SET PROJECTION POLICY <nom>). Si vous sélectionnez cette méthode, la colonne n’est pas protégée par une politique de projection entre le détachement d’une politique et l’affectation d’une autre. Pendant ce temps, une requête pourrait potentiellement accéder à des données sensibles.

Découverte des politiques de projection¶

Vous pouvez utiliser la vue PROJECTION_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 de projection de votre compte Snowflake. Par exemple :

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.PROJECTION_POLICIES
ORDER BY POLICY_NAME;

Copy

Identification des références aux politiques de projection¶

La fonction de table Information Schema POLICY_REFERENCES peut identifier les références aux politiques de projection. Il existe deux options syntaxiques différentes :

1. Renvoie une ligne pour chaque objet (c’est-à-dire une table ou une vue) pour lequel la politique de projection spécifiée est définie sur une colonne :

   USE DATABASE my_db;
   SELECT policy_name,
          policy_kind,
          ref_entity_name,
          ref_entity_domain,
          ref_column_name,
          ref_arg_column_names,
          policy_status
   FROM TABLE(information_schema.policy_references(policy_name => 'my_db.my_schema.projpolicy'));
   

   Copy

2. Renvoie une ligne pour chaque politique affectée à la table nommée my_table :

   USE DATABASE my_db;
   USE SCHEMA information_schema;
   SELECT policy_name,
          policy_kind,
          ref_entity_name,
          ref_entity_domain,
          ref_column_name,
          ref_arg_column_names,
          policy_status
   FROM TABLE(information_schema.policy_references(ref_entity_name => 'my_db.my_schema.my_table', ref_entity_domain => 'table'));
   

   Copy

Politiques de masquage et d’accès aux lignes¶

Cette section explique comment une politique de projection interagit avec une politique de masquage et une politique d’accès aux lignes.

Plusieurs politiques:

Une colonne peut avoir une politique de masquage et une politique de projection en même temps, et la table contenant cette colonne peut être protégée par une politique d’accès aux lignes. Si l’ensemble des trois politiques sont présentes, Snowflake traite la table et les politiques comme suit :

1. Appliquez des filtres de lignes en fonction de la politique d’accès aux lignes.

2. Déterminez si la requête tente de projeter des colonnes qui sont restreintes par la politique de projection et, si c’est le cas, rejetez la requête.

3. Appliquez des masques de colonnes conformément à la politique de masquage.

Une colonne protégée par une politique de masquage peut également être soumise à des contraintes de projection. Par exemple, une politique de masquage définie sur une colonne contenant des numéros de compte peut être assortie d’une condition autorisant les utilisateurs ayant le rôle personnalisé finance_admin à voir les numéros de compte et d’une autre condition visant à remplacer les numéros de compte par un hachage pour tous les autres rôles.

Une politique de projection peut restreindre davantage la colonne, de sorte que les utilisateurs ayant le rôle personnalisé analyst ne puissent pas projeter la colonne. Notez que les utilisateurs ayant le rôle personnalisé analyst peuvent tout de même analyser la colonne en regroupant les hachages ou en les joignant.

Snowflake recommande aux administrateurs de politiques de collaborer avec les responsables internes de la conformité et de la réglementation afin de déterminer les colonnes qui doivent être soumises à des contraintes de projection.

Évaluation des politiques:

Une colonne soumise à des contraintes de projection ne peut pas être référencée par une politique de masquage ou une politique d’accès aux lignes dans les cas suivants :

• Affectation d’une politique d’accès aux lignes à une table.

• Énumération d’une ou de plusieurs colonnes dans une politique de masquage conditionnelle.

• Lancement d’une recherche dans une table de mappage.

Comme mentionné à la section Limitations (dans ce chapitre), une politique de projection body ne peut pas référencer une colonne protégée par une politique de masquage ou une table protégée par une politique d’accès aux lignes.

Objets dépendants avec d’autres politiques de projection¶

Considérons la série d’objets suivante :

base_table » v1 » v2

Où :

• v1 est une vue conçue à partir de la table nommée base_table.

• v2 est une vue conçue à partir de v1.

S’il existe une requête sur une colonne d’une vue soumise à des contraintes de projection et que cette colonne dépend d’une colonne soumise à des contraintes de projection dans base_table, la colonne de la vue ne sera projetée que si les deux politiques de projection permettent la projection de la colonne.

Snowflake vérifie la chaîne de traçabilité de la colonne en remontant jusqu’à la table de base pour s’assurer qu’aucune référence à la colonne n’est soumise à des contraintes de projection. Si une colonne de la chaîne de traçabilité est soumise à des contraintes de projection et que la colonne n’est pas autorisée à être projetée, Snowflake bloque la requête.

Vues et vues matérialisées¶

Une politique de projection sur une colonne d’une vue contraint la colonne de la vue et non la colonne de la table de base sous-jacente.

En ce qui concerne les références, une politique de projection qui contraint une colonne d’une table est transférée à une vue qui fait référence à la colonne de table contrainte.

Flux et tâches¶

Les politiques de projection sur des colonnes d’une table sont transférées à un flux de la même table. Notez qu’une politique de projection ne peut pas être définie sur un flux.

De même, une colonne soumise à des contraintes de projection reste contrainte lorsqu’une tâche fait référence à la colonne contrainte.

UNPIVOT¶

Le résultat d’une construction UNPIVOT dépend du fait qu’une colonne a été initialement contrainte ou non par une politique de projection. Remarque :

• Les colonnes contraintes avant et après l’exécution de UNPIVOT restent soumises à des contraintes de projection.

• Le name_column apparaît toujours dans le résultat de la requête.

• Si l’une des colonnes de la column_list est soumise à des contraintes de projection, value_column l’est également.

Objets clonés¶

L’approche suivante permet de protéger les données des utilisateurs titulaires du privilège SELECT sur une table ou une vue clonée stockée dans la base de données ou le schéma cloné :

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

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

• Une table clonée mappe vers les mêmes politiques de projection que la table source.

  • 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 de projection 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 de projection clonée.

  • Si la table source fait référence à une politique de projection 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.

Réplication¶

Les politiques de projection et leurs affectations peuvent être répliquées à l’aide de la réplication de base 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 a une référence pendante à une politique de projection 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.

Fonctions définies par l’utilisateur (UDFs)¶

Notez les points suivants concernant les contraintes de projection et les UDFs :

UDFs SQL scalaires:

Snowflake évalue l’UDF et applique ensuite la politique de projection à la colonne soumise à des contraintes de projection.

Si une colonne d’une instruction SELECT est dérivée de manière transitive d’une UDF, qui est elle-même dérivée d’une colonne soumise à des contraintes de projection, Snowflake bloque la requête. En d’autres termes :

Colonne pc_column » UDF » (dans l’instruction SELECT)

Où :

• pc_column fait référence à une colonne soumise à des contraintes de projection.

Comme la colonne de l’instruction SELECT peut être rattachée à une colonne soumise à des contraintes de projection, Snowflake bloque la requête.

SQL UDTFs:

Les fonctions de table définies par l’utilisateur (UDTF) SQL suivent le même comportement que les UDFs SQL, sauf qu’étant donné que les lignes sont renvoyées dans la sortie de la fonction, Snowflake évalue chaque colonne de la table indépendamment pour déterminer s’il faut projeter la colonne dans la sortie de la fonction.

Autres UDFs:

Les points suivants s’appliquent à Introduction aux UDFs Java, Présentation des UDFs JavaScript, Introduction aux UDFs Python :

• Une colonne soumise à des contraintes de projection est contrainte dans la sortie UDTF.

Journalisation et tables d’événements:

Lorsqu’une UDF, une UDTF ou une UDF JavaScript a un argument soumis à des contraintes de projection, Snowflake ne capture pas les détails des journaux et des événements dans la table d’événements correspondante. Cependant, Snowflake autorise l’exécution de l’UDF/UDTF et ne fait pas échouer l’instruction appelant l’UDF/UDTF pour des raisons de journalisation.

Privilèges des politiques de projection¶

Snowflake prend en charge les privilèges suivants sur l’objet d’une politique de projection.

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 plus de détails, voir Résumé des commandes, des opérations et des privilèges DDL (dans ce chapitre).

Référence aux DDL des politiques de session¶

Snowflake prend en charge les DDL suivantes pour créer et gérer des politiques de projection.

• CREATE PROJECTION POLICY

• ALTER PROJECTION POLICY

• DESCRIBE PROJECTION POLICY

• DROP PROJECTION POLICY

• SHOW PROJECTION POLICIES

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

Le tableau suivant résume la relation entre les privilèges des politiques de la projection et les opérations DDL.

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 de projection sur un objet.

1. Pour une approche de gestion centralisée des politiques de projection, dans laquelle le rôle personnalisé projection_policy_admin crée et définit des politiques de projection sur toutes les colonnes, les autorisations suivantes sont nécessaires :

   USE ROLE securityadmin;
   GRANT USAGE ON DATABASE mydb TO ROLE projection_policy_admin;
   GRANT USAGE ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   
   GRANT CREATE PROJECTION POLICY ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   GRANT APPLY ON PROJECTION POLICY ON ACCOUNT TO ROLE projection_policy_admin;
   

   Copy

2. Dans une approche de gestion hybride, un seul rôle dispose du privilège CREATE PROJECTIONPOLICY pour garantir que les politiques de projection soient nommées de manière cohérente, et des équipes ou rôles individuels disposent du privilège APPLY pour une politique de projection spécifique.

   Par exemple, le rôle personnalisé finance_role peut se voir accorder l’autorisation de définir la politique de projection cost_center sur les tables et les vues que le rôle possède (c’est-à-dire que le rôle détient le privilège OWNERSHIP sur la table ou la vue) :

   USE ROLE securityadmin;
   GRANT CREATE PROJECTION POLICY ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   GRANT APPLY ON PROJECTION POLICY cost_center TO ROLE finance_role;
   

   Copy