Guida alla Differential Privacy di Snowflake: proteggi i dati sensibili

A cura di César Segura, Subject Matter Expert in SDG Group.

La Data Governance è un pilastro fondamentale di qualsiasi piattaforma dati moderna e deve essere considerata fin dalla fase di progettazione dell'architettura.

All'interno della Data Governance, la privacy e la sicurezza dei dati rappresentano un passaggio cruciale.

Se negli altri articoli della serie su Medium dedicata alla sicurezza ci siamo concentrati sulla gestione degli accessi, in questo articolo analizziamo una specifica privacy policy offerta da Snowflake: la Differential Privacy Policy (DPP).

L'obiettivo principale della DPP è introdurre un "rumore" statistico in una tabella o vista che contiene dati sensibili (PII).

In questo modo, gli utenti con accesso limitato possono continuare a eseguire query sui dati in forma aggregata, ma non saranno in grado di visualizzare le informazioni sensibili a livello individuale.

In questo articolo vedremo tre aspetti chiave:

• Come si crea una Differential Privacy Policy? Forniremo una panoramica del processo.

• Come funziona con esempi pratici? Mostreremo con un caso d'uso semplice come la DPP aggiunge "rumore" ai dati.

• Perché si chiama "Differential Privacy"? Ne capiremo la logica alla base del nome.

1. Come creare una Differential Privacy Policy in Snowflake

Quando si crea una DPP è necessario definire le condizioni per cui la policy si applica a un determinato ruolo che interroga una tabella.

Quando una condizione viene soddisfatta, Snowflake utilizza un "budget" di privacy, generato automaticamente all'interno della policy stessa.

Questo budget limita l'uso che un ruolo specifico può fare della tabella protetta.

Il budget può essere configurato in base a:

• Numero di query di aggregazione eseguite.

• Unità consumate (ogni query consuma unità a seconda del "rumore" necessario).

• Una finestra temporale (settimanale, mensile, ecc.).

I valori predefiniti del budget possono essere modificati in qualsiasi momento.

Ecco un esempio di script Snowflake per creare la policy:

CREATE OR REPLACE PRIVACY POLICY security_db.policies_schema.customers_policy 
AS () RETURNS PRIVACY_BUDGET ->
CASE
  WHEN CURRENT_ROLE() = 'ACCOUNTADMIN' THEN NO_PRIVACY_POLICY()
  WHEN CURRENT_ROLE() IN ('ROLE_1') THEN PRIVACY_BUDGET(BUDGET_NAME => 'Budget_1')
  WHEN CURRENT_ROLE() IN ('ROLE_2') THEN PRIVACY_BUDGET(BUDGET_NAME => 'Budget_2')
  ELSE PRIVACY_BUDGET(BUDGET_NAME => 'Budget_Rest')
END;

Successivamente, quando si applica la policy a una tabella, è necessario definire la entity key, ovvero la colonna che identifica univocamente un'entità (es. un utente) all'interno della tabella.

Un esempio può essere il seguente:

-- Assegna la privacy policy alla tabella CUSTOMERS_TABLE
ALTER TABLE dp_db.dp_schema.customers_table
ADD PRIVACY POLICY security_db.policies_schema.customers_policy
ENTITY KEY (id);

Infine, si specificano i domini di privacy per le colonne che contengono informazioni sensibili. Questi domini definiscono i possibili valori per una colonna e permettono a Snowflake di inserire un "rumore" coerente con i dati originali durante le query.

Un esempio di quanto detto in precedenza lo si può trovare in questo script:

-- Define privacy domains on CUSTOMERS_TABLE table fields
ALTER TABLE dp_db.dp_schema.customers_table ALTER (
   COLUMN gender 
       SET PRIVACY DOMAIN IN ('Female', 'Male'),
   COLUMN Address 
       SET PRIVACY DOMAIN IN ('BCN', 'SAB', 'MAD', 'TAR'),
   COLUMN Birth_date 
       SET PRIVACY DOMAIN 
           BETWEEN (to_date('01/01/1954'), to_date('12/31/2007'))
);

2. Differential Privacy in azione: un esempio pratico

Immaginiamo uno scenario in cui due ruoli (ADMIN and ROLE_1) eseguono la stessa query su una tabella protetta da una DPP. 

Caso 1: la query è eseguita dal ruolo ACCOUNTADMIN

1. Verifica della Policy: il Service Layer di Snowflake controlla se la query è soggetta a una DPP. Poiché abbiamo specificato NO_PRIVACY_POLICY() per il ruolo ACCOUNTADMIN, non viene applicato alcun budget.
2. Iniezione di rumore: la funzione di iniezione del rumore non si attiva.
3. Esecuzione: la query viene eseguita direttamente sulla tabella CUSTOMERS_TABLE. Il risultato sarà sempre deterministico (cioè, sempre lo stesso a parità di dati).
4. Risultato: la query restituisce il risultato esatto.

Caso 2: la query è eseguita dal ruolo ROLE_1 per la prima volta

1. Verifica della policy: il Service Layer rileva che la query è soggetta a una policy, poiché la condizione CURRENT_ROLE() IN ('ROLE_1') è soddisfatta. Viene quindi attivato il Budget_1.
2. Iniezione di rumore: Snowflake attiva l'iniezione di rumore, generando un set di dati "rumoroso" sottostante basato sui PRIVACY DOMAIN definiti in precedenza.
3. Consumo del budget: il Budget_1 viene decrementato. Sia il contatore delle query di aggregazione (Nbr_Agg) sia le unità accumulate (Accumulated Unit Spent) vengono aggiornati.
4. Esecuzione: la query viene eseguita sulla vista "rumorosa" derivata dalla tabella originale. Il risultato sarà non deterministico.
5. Risultato: la query restituisce un risultato aggregato a cui è stato aggiunto del rumore.

Caso 3: ROLE_1 esegue di nuovo la stessa query

Il processo si ripete. Poiché l'iniezione di rumore avviene a ogni esecuzione, il risultato della query sarà ancora una volta non deterministico e probabilmente diverso dal precedente. Il Budget_1 continuerà a essere consumato a ogni esecuzione, fino al suo esaurimento.

3. Perché si chiama "Differential Privacy"?

Il nome deriva dal fatto che, quando una DPP è attiva, l'output di una query non è deterministico. A ogni esecuzione, viene applicato del "rumore" che altera il risultato. La "differenza" tra il valore corretto (quello deterministico) e il valore "rumoroso" restituito dà il nome a questa policy di sicurezza.

È possibile utilizzare le funzioni DP_INTERVAL_LOW e DP_INTERVAL_HIGH per determinare i margini differenziali applicati al risultato, con un livello di affidabilità del 95%.

Un esempio di utilizzo di questa query:

Conclusioni

La Differential Privacy Policy è una delle policy di privacy più complesse e potenti in Snowflake. È uno strumento estremamente utile in ambienti in cui si condividono dati sensibili e si desidera limitarne fortemente l'utilizzo, pur consentendo analisi aggregate.

Prima di applicare questa o altre funzionalità di sicurezza, è fondamentale analizzare a fondo il proprio caso d'uso. Snowflake offre una gamma completa di policy per garantire il giusto livello di protezione per ogni esigenza.

Vuoi garantire il massimo livello di sicurezza per i dati sensibili sulla tua piattaforma Snowflake?

Contattaci per una consulenza personalizzata e scopri come le funzionalità avanzate di Data Governance di Snowflake, come la Differential Privacy, possono proteggere le tue informazioni più critiche, garantendo compliance e analisi sicure.