Commencer avec la protection différentielle de la vie privée¶

Introduction¶

Ce tutoriel montre comment protéger les données sensibles à l’aide d’une politique de confidentialité différentielle afin que vous puissiez les partager en toute sécurité avec les analystes.

Créer des rôles, un entrepôt et des données¶

Dans cette section, vous effectuerez les étapes de configuration suivantes :

• Créez un rôle pour l’analyste.

• Créez l’entrepôt utilisé pour exécuter les requêtes sur les données protégées.

• Créez des simulacres de données sensibles qui seront protégées par la politique de confidentialité.

Aucune de ces étapes de configuration n’est spécifique aux politiques de confidentialité différentielles. S’il existe déjà un rôle, un entrepôt et/ou un jeu de données appropriés, vous pouvez les utiliser à la place.

USE ROLE ACCOUNTADMIN;
CREATE ROLE dp_tutorial_analyst;

-- You can find your own user name by running "SELECT CURRENT_USER();"
GRANT ROLE dp_tutorial_analyst TO USER <user_name>;

CREATE OR REPLACE WAREHOUSE dp_tutorial_wh;
GRANT USAGE ON WAREHOUSE dp_tutorial_wh TO ROLE dp_tutorial_analyst;

-- Create the table
CREATE OR REPLACE DATABASE dp_db;
CREATE OR REPLACE SCHEMA dp_db.dp_schema;
USE SCHEMA dp_db.dp_schema;
CREATE OR REPLACE TABLE dp_tutorial_diabetes_survey (
  patient_id TEXT,
  is_smoker BOOLEAN,
  has_difficulty_walking BOOLEAN,
  gender TEXT,
  age INT,
  has_diabetes BOOLEAN,
  income_code INT);

-- Populate the table
INSERT INTO dp_db.dp_schema.dp_tutorial_diabetes_survey
VALUES
('ID-23493', TRUE, FALSE, 'male', 39, TRUE, 2),
('ID-00923', FALSE, FALSE, 'female', 82, TRUE, 5),
('ID-24020', FALSE, FALSE, 'male', 69, FALSE, 8),
('ID-92848', TRUE, TRUE, 'other', 75, FALSE, 3),
('ID-62937', FALSE, FALSE, 'male', 46, TRUE, 5);

Définir une politique de confidentialité¶

L’application d’une politique de confidentialité à une table ou à une vue la protège avec une confidentialité différentielle et attribue un budget de confidentialité aux groupes ou aux utilisateurs afin que Snowflake puisse empêcher que des requêtes multiples ne révèlent trop d’informations sensibles.

Vous créerez la politique de confidentialité dans sa propre base de données. Il s’agit d’une meilleure pratique pour tous les types de politiques dans Snowflake. Si vous créez la politique dans la même base de données, le clonage de la base de données créerait des copies non synchronisées de la politique. Le fait de placer toutes les politiques dans une seule base de données distincte et de les appliquer à plusieurs tables vous permet de gérer et de mettre à jour une seule copie de chaque politique.

Vous nommerez cette nouvelle politique patients_policy.

-- Define a privacy policy. Use default budget, budget window, max budget per aggregate.
CREATE OR REPLACE DATABASE policy_db;
CREATE OR REPLACE SCHEMA policy_db.diff_priv_policies;
CREATE OR REPLACE PRIVACY POLICY policy_db.diff_priv_policies.patients_policy AS () RETURNS privacy_budget ->
  CASE
    WHEN CURRENT_ROLE() = 'ACCOUNTADMIN' THEN no_privacy_policy()
    WHEN CURRENT_ROLE() IN ('DP_TUTORIAL_ANALYST')
      THEN privacy_budget(budget_name => 'clinical_analysts')
    ELSE privacy_budget(budget_name => 'default')
END;

Remarques :

• La politique de confidentialité appliquée dépend du rôle de l’utilisateur, comme indiqué dans l’instruction CASE. Les noms de rôles sont donnés ici en majuscules car CURRENT_ROLE() renvoie des valeurs en majuscules.

• La création de budgets de confidentialité distincts par rôle vous permet de séparer le budget utilisé pour les analystes et les autres utilisateurs, ainsi que de contrôler l’utilisation par chaque groupe.

• Si la politique de protection de la confidentialité aboutit à un budget de protection de la confidentialité valide lors de son évaluation, l’utilisateur ne peut pas effectuer de requêtes SELECT non agrégées, du bruit est ajouté aux résultats et le nombre de requêtes est limité par le budget de protection de la confidentialité pour cette politique.

• Aucune politique de confidentialité n’est appliquée au rôle d’administrateur de compte. Cela signifie que les requêtes exécutées avec ce rôle ne bénéficient pas d’une confidentialité différentielle. Pour indiquer qu’il n’y a pas de politique de confidentialité, vous devez renvoyer no_privacy_policy() au lieu de renvoyer NULL.

• Le rôle DP_TUTORIAL_ANALYST utilise une politique de confidentialité nommée « clinical_analysts » avec des valeurs par défaut pour le budget de confidentialité, la fenêtre budgétaire et le budget maximum par agrégat.

• Tout autre utilisateur ayant accès à SELECT obtiendra un budget de confidentialité nommé « default », avec également les valeurs par défaut de la politique de confidentialité. Si vous souhaitez empêcher d’autres utilisateurs d’exécuter des requêtes sur cette table, vous devez le faire en limitant les privilèges SELECT sur la table. Les politiques de table exigent une clause ELSE et ne peuvent pas renvoyer NULL.

Attribuer la politique de confidentialité¶

Ensuite, vous attribuerez la politique de confidentialité que vous venez de créer à la table pour la protéger avec la confidentialité différentielle.

-- Assign the privacy policy to the table.
ALTER TABLE dp_db.dp_schema.dp_tutorial_diabetes_survey
ADD PRIVACY POLICY policy_db.diff_priv_policies.patients_policy ENTITY KEY (patient_id);

Remarques :

La clause ENTITY KEY spécifie une colonne qui identifie de manière unique l’entité qui doit être protégée par la confidentialité différentielle. Dans ce tutoriel, qui présente une table unique où chaque entité est listée dans une et une seule ligne, la définition de la clé de l’entité est moins importante. Mais si chaque patient pouvait apparaître dans plusieurs lignes (par exemple, s’il s’agissait de saisir les visites ou les médicaments des patients), il serait alors important de définir la clé. Il est toujours bon de définir la clé ici, au cas où une deuxième table de ce type serait ajoutée ultérieurement à la base de données. Pour en savoir plus sur la confidentialité au niveau de l’entité.

Définir un domaine de confidentialité¶

Ensuite, vous allez définir des domaines de confidentialité sur certaines colonnes de la table.

Un domaine de confidentialité indique au système la plage de valeurs qui peut être affichée dans les résultats pour cette colonne. Le système utilise ces informations de deux manières :

• Les valeurs situées en dehors de cette plage seront omises ou rattachées aux limites, selon que la colonne est une chaîne ou une valeur numérique/date.

• Le système utilise cette « plage valide » pour déterminer la plage de résultats afin de déterminer le bruit appliqué à chaque valeur de mesure.

Un analyste peut restreindre davantage un domaine, par exemple en utilisant une clause WHERE, afin de réduire potentiellement la quantité de bruit générée par la confidentialité différentielle (plus le domaine est petit, moins il y a de bruit). Si vous ne définissez pas de domaine de confidentialité pour une colonne, l’analyste doit ajouter un domaine de confidentialité avec une clause WHERE pour voir les valeurs de cette colonne (les colonnes sans domaine de confidentialité ne peuvent pas être affichées ou utilisées dans la requête).

Pour les données de l’enquête sur le diabète, vous définirez des paramètres de confidentialité sur trois colonnes : gender, age et income_code. Vous ne définirez pas de domaine de confidentialité sur les colonnes booléennes (avec seulement deux valeurs possibles, un domaine de confidentialité n’a pas de sens et n’est pas nécessaire), et vous ne devriez pas définir de domaine de confidentialité sur la colonne patient_id parce que l’utilisateur peut voir les valeurs que vous avez définies dans le domaine de confidentialité, qui lui indiquerait quels IDs de patients se trouvent dans les données. Si vous devez spécifier un domaine de confidentialité pour un nombre limité de valeurs de chaînes, telles que les codes ZIP, vous devez compléter la définition du domaine par des valeurs supplémentaires non présentes afin d’obscurcir les valeurs possibles.

-- Define privacy domains.
ALTER TABLE dp_db.dp_schema.dp_tutorial_diabetes_survey ALTER (
COLUMN gender SET PRIVACY DOMAIN IN ('female', 'male', 'other'),
COLUMN age SET PRIVACY DOMAIN BETWEEN (0, 90),
COLUMN income_code SET PRIVACY DOMAIN BETWEEN (1, 8)
);

Accorder à l’analyste l’accès à la table¶

N’accordez l’accès à la table qu’après avoir attribué des politiques de confidentialité aux données. Dans le cas contraire, les utilisateurs pourraient voir les données avant que vous n’appliquiez les politiques de confidentialité.

GRANT USAGE ON DATABASE dp_db TO ROLE dp_tutorial_analyst;
GRANT USAGE ON SCHEMA dp_schema TO ROLE dp_tutorial_analyst;
GRANT SELECT
  ON TABLE dp_db.dp_schema.dp_tutorial_diabetes_survey
  TO ROLE dp_tutorial_analyst;

Exécuter quelques requêtes¶

Enfin, vous pouvez commencer à exécuter des requêtes sur vos données !

Vous basculerez entre les rôles d’administrateur et d’analyste afin de comparer le comportement et la sortie pour chaque rôle.

USE ROLE ACCOUNTADMIN;
SELECT * FROM dp_db.dp_schema.dp_tutorial_diabetes_survey;

USE ROLE dp_tutorial_analyst;
SELECT * FROM dp_db.dp_schema.dp_tutorial_diabetes_survey;

-- Run a basic query without DP.
USE ROLE ACCOUNTADMIN;
SELECT COUNT(DISTINCT patient_id)
  FROM dp_db.dp_schema.dp_tutorial_diabetes_survey
  WHERE income_code = 5;

USE ROLE dp_tutorial_analyst;
SELECT COUNT(DISTINCT patient_id)
  FROM dp_db.dp_schema.dp_tutorial_diabetes_survey
  WHERE income_code = 5;

-- Retrieve noise interval for the previous query.
USE ROLE dp_tutorial_analyst;
SELECT COUNT(DISTINCT patient_id) as c,
  DP_INTERVAL_LOW(c) as LOW,
  DP_INTERVAL_HIGH(c) as HIGH
  FROM dp_db.dp_schema.dp_tutorial_diabetes_survey
  WHERE income_code = 5;

USE ROLE <role_name>;
SELECT * FROM TABLE(SNOWFLAKE.DATA_PRIVACY.ESTIMATE_REMAINING_DP_AGGREGATES(dp_db.dp_schema.dp_tutorial_diabetes_survey));

Nettoyage¶

Nettoyez vos ressources afin que vous, ou quelqu’un d’autre dans votre organisation, puissiez exécuter à nouveau le tutoriel plus tard.

USE ROLE ACCOUNTADMIN;
DROP ROLE dp_tutorial_analyst;
DROP WAREHOUSE dp_tutorial_wh;
ALTER TABLE dp_tutorial_diabetes_survey
  DROP PRIVACY POLICY policy_db.diff_priv_policies.patients_policy;
DROP DATABASE dp_db;
DROP DATABASE policies_db;