CREATE PRIVACY POLICY

Crée une politique de confidentialité ou remplace une politique de confidentialité existante.

Voir aussi :

ALTER PRIVACY POLICY, DESCRIBE PRIVACY POLICY, DROP PRIVACY POLICY, SHOW PRIVACY POLICIES

Syntaxe

CREATE [ OR REPLACE ] PRIVACY POLICY [ IF NOT EXISTS ] <name>
  AS () RETURNS PRIVACY_BUDGET -> <body>
  [ COMMENT = '<string_literal>' ]
Copy

Paramètres requis

name

Chaîne qui spécifie l’identificateur (c’est-à-dire le nom) de la politique de confidentialité ; elle doit être unique pour le schéma dans lequel la politique de confidentialité est créée.

De plus, 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 (par exemple, "My object"). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus d’informations, voir Exigences relatives à l’identificateur.

body

L’expression SQL du corps appelle deux fonctions pour contrôler la valeur de retour de la politique : NO_PRIVACY_POLICY et PRIVACY_BUDGET. Lorsqu’une requête est exécutée sur une table à laquelle la politique a été attribuée, Snowflake évalue les conditions du corps pour appeler la fonction appropriée et renvoyer une valeur. Cette valeur de retour détermine quel budget de confidentialité, le cas échéant, est associé à la requête sur la table protégée par la confidentialité.

L’expression peut utiliser des fonctions de contexte telles que CURRENT_ROLE ou INVOKER_ROLE pour associer un utilisateur ou un groupe d’utilisateurs à un budget de confidentialité.

Si vous utilisez un bloc CASE dans l’expression du corps, il doit inclure une instruction ELSE qui appelle NO_PRIVACY_POLICY ou PRIVACY_BUDGET. Chaque utilisateur doit être associé à un budget de confidentialité ou avoir un accès illimité à la table protégée par la confidentialité. Si un utilisateur ne doit pas avoir accès à une table ou à une vue protégée par la confidentialité, révoquez les privilèges SELECT plutôt que d’essayer de définir cela dans la politique de confidentialité.

NO_PRIVACY_POLICY

Utilisez l’expression du corps pour appeler la fonction NO_PRIVACY_POLICY lorsque vous souhaitez qu’une requête ait un accès illimité à la table ou à la vue à laquelle la politique de confidentialité est affectée.

PRIVACY_BUDGET

Utilisez l’expression du corps pour appeler la fonction PRIVACY_BUDGET lorsque vous souhaitez renvoyer un budget de confidentialité à partir de la politique. L’expression peut contenir des conditions qui permettent à la politique de renvoyer différents budgets de confidentialité pour différentes requêtes en fonction de facteurs tels que l’utilisateur qui exécute la requête.

Dans la collaboration entre comptes, les budgets de confidentialité reçoivent automatiquement un espace de noms via l’identificateur de compte du compte consommateur, ce qui empêche deux comptes consommateurs différents de partager le même budget de confidentialité même si le nom du budget de confidentialité est le même. Utiliser la fonction CURRENT_ACCOUNT pour concaténer le nom du compte avec le nom du budget de confidentialité peut aider à distinguer les budgets de confidentialité. Par exemple, vous pouvez appeler la fonction comme suit : PRIVACY_BUDGET(BUDGET_NAME => 'external_budget.' || CURRENT_ACCOUNT()).

La signature de la fonction PRIVACY_BUDGET est :

PRIVACY_BUDGET(
  BUDGET_NAME=> '<string>'
  [, BUDGET_LIMIT=> <decimal> ]
  [, MAX_BUDGET_PER_AGGREGATE=> <decimal> ]
  [, BUDGET_WINDOW=> <string> ]
)
Copy

Arguments du budget de confidentialité :

BUDGET_NAME => expression

Devient le nom d’un budget de confidentialité. Snowflake crée automatiquement le budget de confidentialité lorsque son nom est spécifié dans le corps de la politique de confidentialité.

BUDGET_LIMIT => decimal

Un nombre décimal> 0 qui spécifie la limite budgétaire pour cette politique de confidentialité. Cela contrôle le montant total de perte de confidentialité autorisée. Le réglage de cette valeur modifie le nombre total d’agrégats différentiellement privés qui peuvent être calculés par rapport aux tables protégées par ce budget de confidentialité pendant la période d’actualisation. Lorsqu’une requête est exécutée et que la perte de confidentialité cumulée dépasse ce nombre, la requête échoue. À titre d’estimation approximative, une limite budgétaire de 233 avec MAX_BUDGET_PER_AGGREGATE=1 permet environ 1 000 agrégats par période d’actualisation.

Par défaut : 233,0

MAX_BUDGET_PER_AGGREGATE => decimal

Spécifie le montant du budget de confidentialité utilisé pour chaque fonction d’agrégation dans une requête. Le réglage de cette valeur modifie la quantité de bruit ajoutée à chaque requête agrégée, ainsi que le nombre d’agrégats qui peuvent être calculés avant que la limite budgétaire ne soit atteinte. À titre d’exemple, la requête select count(*), avg(a) ... a deux agrégats : count(*) et avg(a). Spécifier une valeur décimale> 0.

Par défaut : 0,5

BUDGET_WINDOW => string

La fréquence à laquelle le budget de confidentialité est actualisé, c’est-à-dire que sa perte de confidentialité cumulée est réinitialisée à 0. Valeurs valides :

  • Daily : actualisé tous les jours à 12h00 AM UTC

  • Weekly : actualisé tous les dimanches à 12h00 AM UTC

  • Monthly : actualisé le premier jour du mois calendaire à 12h00 AM UTC

  • Yearly : actualisé le 1er janvier à 12h00 AM UTC

  • Never : le budget de confidentialité n’est jamais actualisé.

Par défaut : hebdomadaire

Paramètres facultatifs

COMMENT = 'string_literal'

Spécifie un commentaire pour la politique de confidentialité.

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

Notes sur l’utilisation

  • 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

Créer une politique de confidentialité qui renvoie toujours un budget nommé analysts :

CREATE PRIVACY POLICY my_priv_policy
  AS ( ) RETURNS PRIVACY_BUDGET ->
  PRIVACY_BUDGET(BUDGET_NAME=> 'analysts');
Copy

Créer une politique de confidentialité qui donnera un accès illimité admin à la table protégée par la confidentialité tout en associant tous les autres utilisateurs au budget de confidentialité analysts :

CREATE PRIVACY POLICY my_priv_policy
  AS () RETURNS PRIVACY_BUDGET ->
    CASE
      WHEN CURRENT_USER() = 'ADMIN'
        THEN NO_PRIVACY_POLICY()
      ELSE PRIVACY_BUDGET(BUDGET_NAME => 'analysts')
    END;
Copy
Langage: Français