Politiques d’agrégation¶

Limitations¶

Pour cet aperçu :

• Si la requête utilise une construction de regroupement explicite, il doit s’agir d’une clause GROUP BY. La requête ne peut pas utiliser de constructions associées telles que GROUP BY ROLLUP, GROUP BY CUBE ou GROUP BY GROUPING SETS.

• La plupart des opérateurs d’ensemble ne sont pas autorisés lorsque l’une des requêtes porte sur une table soumise à des contraintes d’agrégation. À titre d’exception, UNION ALL est pris en charge, mais chaque groupe de résultats doit respecter la taille de groupe minimale des tables soumises à des contraintes d’agrégation faisant l’objet de la requête (voir Conditions des requêtes pour des informations détaillées).

• Si une colonne d’une table soumise à des contraintes d’agrégation est protégée par une politique de projection, une requête sur cette table ne peut pas utiliser la colonne comme argument de la fonction COUNT.

• Les CTEs récursifs ne sont pas autorisés dans les requêtes portant sur une table ou une vue soumise à des contraintes d’agrégation.

• Les fonctions de fenêtre ne sont pas autorisées dans les requêtes portant sur une table ou une vue soumise à des contraintes d’agrégation.

• Une requête sur une table soumise à des contraintes d’agrégation ne peut pas utiliser de sous-requête corrélée ni de jointure latérale lorsqu’il existe des références à ou provenant de la portion de la requête qui remplit les conditions de la politique d’agrégation. Les exemples suivants illustrent les types de requêtes interdits.

  Exemple 1

  En supposant que protected_table soit soumise à des contraintes d’agrégation, la requête suivante n’est pas autorisée, car la portion de la requête qui agrège les données fait référence à une autre partie de la requête en dehors de la sous-requête :

  SELECT c1, c2
  FROM open_table
  WHERE c1 = (SELECT x FROM protected_table WHERE y = open_table.c2);
  

  Copy

  Exemple 2

  En supposant que protected_table soit soumise à des contraintes d’agrégation, la requête suivante n’est pas autorisée, car la sous-requête fait référence à la partie de la requête qui agrège les données, qui se trouve en dehors de la sous-requête :

  SELECT
    SUM(SELECT COUNT(*) FROM open_table ot WHERE pt.id = ot.id)
  FROM protected_table pt;
  

  Copy

Considérations¶

Tenez compte des points suivants lorsque vous utilisez des politiques d’agrégation pour protéger des données sensibles :

• Les politiques d’agrégation protègent les données d’un enregistrement individuel et non d’une entité. Si un ensemble de données contient plusieurs enregistrements appartenant à la même entité, une politique d’agrégation ne protège que la confidentialité d’un enregistrement spécifique appartenant à cette entité et non de l’ensemble de l’entité.

• Si les politiques d’agrégation limitent l’accès aux enregistrements individuels, elles ne garantissent pas qu’un acteur malveillant ne puisse pas utiliser des requêtes délibérées pour obtenir des données potentiellement sensibles provenant d’une table soumise à des contraintes d’agrégation. Avec un nombre suffisant de tentatives de requête, un acteur malveillant pourrait potentiellement contourner les conditions d’agrégation pour déterminer une valeur à partir d’une ligne individuelle. Les politiques d’agrégation 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 exemple, en examinant l’historique des accès à leurs annonces).

Appel des fonctions internes du corps¶

Le corps d’une politique d’agrégation utilise deux fonctions internes pour définir les contraintes de la politique : NO_AGGREGATION_CONSTRAINT et AGGREGATION_CONSTRAINT. Lorsque les conditions du corps appellent l’une de ces fonctions, la valeur de retour de la fonction détermine la manière dont les requêtes portant sur la table ou la vue soumise à des contraintes d’agrégation doivent être formulées pour renvoyer des résultats.

NO_AGGREGATION_CONSTRAINT

Lorsque le corps de la politique renvoie une valeur de cette fonction, les requêtes peuvent renvoyer sans restriction les données d’une table ou d’une vue soumise à des contraintes d’agrégation. Par exemple, le corps de la politique peut appeler cette fonction lorsqu’un administrateur a besoin d’obtenir des résultats non agrégés provenant de la table ou de la vue soumise à des contraintes d’agrégation.

Appelez NO_AGGREGATION_CONSTRAINT sans argument.

AGGREGATION_CONSTRAINT

Lorsque le corps de la politique renvoie une valeur de cette fonction, les requêtes doivent agréger les données afin de renvoyer des résultats. Utilisez l’argument MIN_GROUP_SIZE pour spécifier le nombre d’enregistrements à inclure dans chaque groupe d’agrégation.

La syntaxe de la fonction AGGREGATION_CONSTRAINT est la suivante :

AGGREGATION_CONSTRAINT ( MIN_GROUP_SIZE => <integer_expression> )

Copy

Où integer_expression correspond à la taille de groupe minimale de la politique.

Il existe une différence entre transmettre un 1 et transmettre un 0 comme argument à la fonction. Dans les deux cas, les résultats doivent être agrégés.

• La transmission d’un 1 exige également que chaque groupe d’agrégation contienne au moins un enregistrement de la table soumise à des contraintes d’agrégation. Ainsi, pour les jointures externes, au moins un enregistrement de la table soumise à des contraintes d’agrégation doit correspondre à un enregistrement d’une table non protégée.

• La transmission d’un 0 permet à la requête de renvoyer des groupes entièrement constitués d’enregistrements provenant d’une autre table. Ainsi, pour les jointures externes entre une table soumise à des contraintes d’agrégation et une table non protégée, un groupe peut être constitué d’enregistrements de la table non protégée qui ne correspondent à aucun enregistrement de la table soumise à des contraintes d’agrégation.

Exemples de politiques¶

Taille de groupe minimale fixe

La politique d’agrégation la plus simple appelle directement la fonction AGGREGATION_CONSTRAINT et définit une taille de groupe minimale constante appliquée à toutes les requêtes portant sur la table. Par exemple, la commande suivante crée une politique d’agrégation de taille de groupe minimale égale à 5 :

CREATE AGGREGATION POLICY my_agg_policy
  AS () RETURNS AGGREGATION_CONSTRAINT -> AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5);

Copy

Politique conditionnelle

Les administrateurs de politiques peuvent définir l’expression SQL d’une politique d’agrégation afin que différentes requêtes aient des restrictions différentes en fonction de facteurs tels que le rôle de l’utilisateur qui exécute la requête. Cette stratégie peut permettre à un utilisateur d’interroger une table sans restriction tout en obligeant les autres à agréger les résultats.

Par exemple, la politique d’agrégation suivante donne aux utilisateurs titulaires du rôle ADMIN un accès illimité à une table tout en exigeant que toutes les autres requêtes agrègent les données en groupes d’au moins 5 lignes.

CREATE AGGREGATION POLICY my_agg_policy
  AS () RETURNS AGGREGATION_CONSTRAINT ->
    CASE
      WHEN CURRENT_ROLE() = 'ADMIN'
        THEN NO_AGGREGATION_CONSTRAINT()
      ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5)
    END;

Copy

Remplacement d’une politique d’agrégation¶

La méthode recommandée pour remplacer une politique d’agrégation consiste à utiliser le paramètre FORCE pour détacher la politique d’agrégation existante et affecter la nouvelle politique 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 d’agrégation à une table déjà soumise à des contraintes d’agrégation :

ALTER TABLE privacy SET AGGREGATION POLICY agg_policy_2 FORCE;

Vous pouvez également détacher la politique d’agrégation d’une table ou d’une vue dans une instruction (… UNSET AGGREGATION POLICY), puis définir une nouvelle politique sur la table ou la vue dans une autre instruction (… SET AGGREGATION POLICY <nom>). Si vous sélectionnez cette méthode, la table n’est pas protégée par une politique d’agrégation 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 d’agrégation¶

Vous pouvez utiliser la vue AGGREGATION_POLICIES dans le schéma Account Usage de la base de données partagée SNOWFLAKE. Cette vue est un catalogue de toutes les politiques d’agrégation de votre compte Snowflake. Par exemple :

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

Copy

Identification des références aux politiques d’agrégation¶

La fonction de table Information Schema POLICY_REFERENCES peut identifier les références aux politiques d’agrégation. 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 d’agrégation spécifiée est définie :

   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(policy_name => 'my_db.my_schema.aggpolicy'));
   

   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

Autres politiques¶

Cette section décrit comment une politique d’agrégation interagit avec d’autres politiques, notamment des politiques de masquage, des politiques d’accès aux lignes et des politiques de projection.

Vous pouvez attacher d’autres politiques à une table soumise à des contraintes d’agrégation. Une requête réussie sur la table doit remplir les conditions de toutes les politiques.

Si une politique d’accès aux lignes est affectée à une table soumise à des contraintes d’agrégation, une ligne exclue des résultats de la requête en fonction de la politique d’accès aux lignes n’est pas incluse lors du calcul des résultats agrégés.

Le corps d’une politique de masquage, d’une politique d’accès aux lignes ou d’une politique de projection ne peut pas faire référence à une table soumise à des contraintes d’agrégation ni à ses colonnes. De même, le corps de l’autre politique ne peut pas inclure un UDF faisant référence à la table soumise à des contraintes d’agrégation.

Vues et vues matérialisées¶

Vous pouvez affecter une politique d’agrégation à des vues et à des vues matérialisées. Lorsqu’une politique d’agrégation est appliquée à une vue, la table sous-jacente ne devient pas soumise à des contraintes d’agrégation. Cette table de base peut continuer à être interrogée sans restriction.

Pour éviter la possibilité d’exposer des données sensibles, toutes les vues soumises à des contraintes d’agrégation sont traitées comme s’il s’agissait de vues sécurisées, même si elles n’en sont pas.

La possibilité de créer une vue à partir d’une table soumise à des contraintes d’agrégation dépend du type de vue :

• Vous pouvez créer une vue normale à partir d’une ou de plusieurs tables soumises à des contraintes d’agrégation, mais les requêtes portant sur cette vue doivent agréger les données d’une manière qui respecte les restrictions de ces tables de base.

• Vous ne pouvez pas créer de vue matérialisée à partir d’une table ou d’une vue soumise à des contraintes d’agrégation ni affecter une politique d’agrégation à une table ou à une vue sur laquelle une vue matérialisée est basée.

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 d’agrégation individuel n’est pas pris en charge.

• Le clonage d’une base de données entraîne le clonage de toutes les politiques d’agrégation de la base de données.

• Le clonage d’un schéma entraîne le clonage de toutes les politiques d’agrégation du schéma.

• Une table clonée est mappée vers les mêmes politiques que celles de 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 d’agrégation 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 d’agrégation clonée.

  • Si la table source fait référence à une politique d’agrégation 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 d’agrégation et leurs affectations peuvent être répliquées à l’aide de la réplication de bases de données et de groupes de réplication.

Pour la réplication de base de données, l’opération de réplication échoue si l’une des conditions suivantes est vraie :

• La base de données principale se trouve dans un compte Enterprise (ou supérieur) et contient une politique, mais au moins un des comptes approuvés pour la réplication se trouve sur des éditions inférieures.

• Une table ou une vue contenue dans la base de données principale a une référence pendante à une politique d’agrégation 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.

Privilèges des politiques d’agrégation¶

Snowflake prend en charge les privilèges suivants sur l’objet de politique d’agrégation.

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 DDL d’une politique d’agrégation¶

Snowflake prend en charge les DDL suivantes pour créer et gérer les politiques d’agrégation.

• CREATE AGGREGATION POLICY

• ALTER AGGREGATION POLICY

• DESCRIBE AGGREGATION POLICY

• DROP AGGREGATION POLICY

• SHOW AGGREGATION 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 d’agrégation 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 d’agrégation sur un objet.

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

   USE ROLE securityadmin;
   GRANT USAGE ON DATABASE mydb TO ROLE agg_policy_admin;
   GRANT USAGE ON SCHEMA mydb.schema TO ROLE proj_policy_admin;
   GRANT CREATE AGGREGATION POLICY ON SCHEMA mydb.schema TO ROLE aggregation_policy_admin;
   GRANT APPLY ON AGGREGATION POLICY ON ACCOUNT TO ROLE aggregation_policy_admin;
   

   Copy

2. Dans une approche de gestion hybride, un rôle unique dispose du privilège CREATE AGGREGATIONPOLICY pour garantir que les politiques d’agrégation sont nommées de manière cohérente, et des équipes ou rôles individuels disposent du privilège APPLY pour une politique d’agrégation spécifique.

   Par exemple, le rôle personnalisé finance_role peut se voir accorder l’autorisation de définir la politique d’agrégation 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 AGGREGATION POLICY ON SCHEMA mydb.schema TO ROLE aggregation_policy_admin;
   GRANT APPLY ON AGGREGATION POLICY cost_center TO ROLE finance_role;
   

   Copy