Erste Schritte mit Differential Privacy¶

Einführung¶

Dieses Tutorial zeigt Ihnen, wie Sie sensible Daten mit einer Richtlinie für differentielle Privatsphäre (Differential Privacy) schützen können, damit Sie sie sicher mit Analysten teilen können.

Erstellen Sie Rollen, ein Warehouse und Daten¶

In diesem Abschnitt werden Sie die folgenden Einrichtungsschritte durchführen:

• Erstellen Sie eine Rolle für den Analysten.

• Erstellen Sie das Warehouse, mit dem Sie die Abfragen gegen die geschützten Daten ausführen.

• Erstellen Sie nachgebildete sensible Daten, die durch die Datenschutzrichtlinie geschützt werden.

Keiner dieser Einrichtungsschritte ist spezifisch für Richtlinien für differentielle Privatsphäre. Wenn es bereits eine passende Rolle, ein passendes Warehouse und/oder einen passenden Datasatz gibt, können Sie diese stattdessen verwenden.

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);

Definieren Sie eine Datenschutzrichtlinie¶

Die Anwendung einer Datenschutzrichtlinie auf eine Tabelle oder Ansicht schützt diese mit differentieller Privatsphäre und weist Gruppen oder Benutzern ein Datenschutzbudget zu, sodass Snowflake verhindern kann, dass mehrere Abfragen zu viele sensible Informationen preisgeben.

Sie erstellen die Datenschutzrichtlinie in einer eigenen Datenbank. Dies ist eine bewährte Vorgehensweise für alle Arten von Richtlinien in Snowflake. Wenn Sie die Richtlinie in der gleichen Datenbank erstellen, würde das Klonen der Datenbank unsynchronisierte Kopien der Richtlinie erzeugen. Wenn Sie alle Richtlinien in einer einzigen, separaten Datenbank speichern und sie auf mehrere Tabellen anwenden, können Sie eine einzige Kopie jeder Richtlinie verwalten und aktualisieren.

Sie werden diese neue Richtlinie patients_policy nennen.

-- 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;

Anmerkungen:

• Die angewandte Datenschutzrichtlinie hängt von der Rolle des Benutzers ab, wie in der CASE-Anweisung angegeben. Rollennamen werden hier in Großbuchstaben angegeben, da CURRENT_ROLE() Werte in Großbuchstaben zurückgibt.

• Durch die Erstellung separater Datenschutzbudgets pro Rolle können Sie das für Analysten und andere Benutzer verwendete Budget trennen und die Nutzung durch die einzelnen Gruppen überwachen.

• Wenn die Datenschutzrichtlinie bei der Auswertung ein gültiges Datenschutzbudget ergibt, kann der Benutzer keine nicht aggregierten SELECT-Abfragen durchführen, den Ergebnissen wird Rauschen hinzugefügt, und die Anzahl der Abfragen wird durch das Datenschutzbudget für diese Richtlinie begrenzt.

• Für die Kontoadministratorrolle gilt keine Datenschutzrichtlinie. Das bedeutet, dass für Abfragen, die in dieser Rolle ausgeführt werden, kein besonderer Datenschutz gilt. Wenn Sie keine Datenschutzrichtlinie angeben möchten, müssen Sie no_privacy_policy() zurückgeben, anstatt NULL zurückzugeben.

• Die Rolle DP_TUTORIAL_ANALYST verwendet eine Datenschutzrichtlinie mit dem Namen „clinical_analysts“ mit Standardwerten für Datenschutzbudget, Budgetfenster und maximales Budget pro Aggregat.

• Jeder andere Benutzer mit SELECT-Zugriff erhält ein Datenschutzbudget mit dem Namen „default“, ebenfalls mit Standardwerten für die Datenschutzrichtlinie. Wenn Sie verhindern wollen, dass andere Benutzer Abfragen auf dieser Tabelle ausführen, sollten Sie die SELECT-Berechtigungen für diese Tabelle einschränken. Richtlinien auf Tabellenebene erfordern eine ELSE-Klausel und können nicht NULL zurückgeben.

Zuweisen der Datenschutzrichtlinie¶

Als Nächstes weisen Sie der Tabelle die soeben erstellte Datenschutzrichtlinie zu, um sie mit differentieller Privatsphäre zu schützen.

-- 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);

Anmerkungen:

Die Klausel ENTITY KEY gibt eine Spalte an, die die Entität, die durch die differentielle Privatsphäre geschützt werden soll, eindeutig identifiziert. In diesem Tutorial, in dem es um eine einzige Tabelle geht, in der jede Entität in einer einzigen Zeile aufgeführt ist, ist die Definition des Entitätsschlüssels weniger wichtig. Wenn jedoch jeder Patient in mehreren Zeilen auftauchen könnte (z. B. wenn Patientenbesuche oder Patientenmedikationen erfasst werden), wäre die Definition des Schlüssels wichtig. Es ist immer noch eine gute Vorgehensweise, den Schlüssel hier zu definieren, für den Fall, dass später eine zweite solche Tabelle zur Datenbank hinzugefügt wird. Erfahren Sie mehr über Datenschutz auf Entitätsebene.

Definieren Sie einen Datenschutzbereich¶

Als Nächstes richten Sie Datenschutzbereiche für ausgewählte Spalten in der Tabelle ein.

Ein Datenschutzbereich teilt dem System den Wertebereich mit, der in den Ergebnissen für diese Spalte angezeigt werden kann. Das System verwendet diese Informationen auf zwei Arten:

• Werte, die außerhalb dieses Bereichs liegen, werden ausgelassen oder an die Grenzen angehängt, je nachdem, ob es sich bei der Spalte um eine Zeichenfolge oder einen numerischen Wert / Datumswert handelt.

• Das System verwendet diesen „gültigen Bereich“, um den Bereich der Ergebnisse zu bestimmen, um das auf jeden Messwert angewandte Rauschen zu ermitteln.

Ein Analyst kann einen Bereich weiter einschränken, z. B. durch die Verwendung einer WHERE-Klausel, um die Menge des Rauschens, das durch die differentielle Privatsphäre entsteht, zu reduzieren (je kleiner der Bereich, desto weniger Rauschen). Wenn Sie für eine Spalte keine Datenschutzdomäne festlegen, muss der Analyst eine Datenschutzdomäne mit einer WHERE-Klausel hinzufügen, um Werte für diese Spalte anzuzeigen (Spalten ohne Datenschutzdomäne können nicht angezeigt oder in der Abfrage verwendet werden).

Für die Diabetes-Umfragedaten werden Sie Datenschutzbereiche für drei Spalten festlegen: gender, age und income_code. Sie werden keine Datenschutzdomänen für boolesche Spalten festlegen (bei nur zwei möglichen Werten ist eine Datenschutzdomäne nicht sinnvoll und auch nicht erforderlich), und Sie sollten keine Datenschutzdomäne für die Spalte patient_id festlegen, da der Benutzer die Werte sehen kann, die Sie in der Datenschutzdomäne festgelegt haben und die ihm zeigen würden, welche Patienten-IDs in den Daten enthalten sind. Wenn Sie eine Datenschutzdomäne für eine begrenzte Anzahl von Zeichenkettenwerten angeben müssen, wie z. B. ZIP-Codes, sollten Sie die Domänendefinition mit zusätzlichen, nicht vorhandenen Werten auffüllen, um mögliche Werte zu verschleiern.

-- 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)
);

Gewähren Sie dem Analysten Zugriff auf die Tabelle¶

Gewähren Sie den Zugriff auf die Tabelle erst, nachdem Sie den Daten Datenschutzrichtlinien zugewiesen haben. Andernfalls könnten die Benutzer die Daten sehen, bevor Sie Datenschutzrichtlinien anwenden.

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;

Führen Sie einige Abfragen aus¶

Endlich können Sie Abfragen auf Ihre Daten durchführen!

Sie werden zwischen den Rollen Admin und Analyst wechseln, um die Verhaltensweise und die Ausgabe für jede Rolle zu vergleichen.

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));

Bereinigen¶

Bereinigen Sie Ihre Ressourcen, damit Sie oder jemand anderes in Ihrer Organisation das Tutorial später noch einmal ausführen kann.

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;