Privacy dei dati per l'analisi su scala cloud in Azure

  • Articolo

L'analisi su scala cloud consente alle organizzazioni di determinare i modelli migliori per soddisfare i propri requisiti, sorvegliando i dati personali a più livelli. I dati personali sono le informazioni che consentono l'identificazione personale, ad esempio numeri di patente, codici fiscali, numeri di conti bancari, numeri di passaporto, indirizzi di posta elettronica e altro ancora. Oggi esistono numerose normative volte a proteggere la privacy degli utenti.

Schema di classificazione della riservatezza dei dati

Classificazione Descrizione
Pubblica Chiunque può accedere ai dati e può essere inviato a chiunque. Ad esempio, aprire i dati per enti pubblici.
Solo per uso interno. Solo i dipendenti possono accedere ai dati e non possono essere inviati all'esterno dell'azienda.
Riservati I dati possono essere condivisi solo se sono necessari per un'attività specifica. I dati non possono essere inviati all'esterno dell'azienda senza un accordo di non divulgazione.
Sensibili (dati personali) I dati contengono informazioni private, che devono essere mascherate e condivise solo per un periodo di tempo limitato. I dati non possono essere inviati a personale non autorizzato o all'esterno dell'azienda.
Limitata I dati possono essere condivisi solo con persone denominate che sono responsabili della protezione. Ad esempio, documenti legali o segreti commerciali.

Prima di inserire i dati, è necessario classificarli come riservati o categorie inferiori oppure come sensibili (dati personali):

  • I dati possono essere classificati come riservati o categorie inferiori se un utente ottiene l'accesso all'asset di dati arricchito o curato. Gli utenti possono visualizzare tutte le colonne e le righe.

  • I dati possono essere classificati come sensibili (dati personali) in presenza di restrizioni per cui le colonne e le righe sono visibili a utenti diversi.

Importante

Un set di dati può passare da riservati o categorie inferiori a sensibili (dati personali) quando i dati vengono combinati. Nelle situazioni in cui i dati devono essere persistenti, devono essere copiati in una cartella separata allineata alla classificazione di riservatezza dei dati e al processo per il relativo onboarding.

Riservati o categorie inferiori

Per ogni prodotto di dati di cui è stato eseguito l'onboarding, vengono create due cartelle data lake nei livelli arricchiti e curati, riservati o inferiori e sensibili (dati personali) e vengono usati elenchi di controllo di accesso per abilitare l'autenticazione pass-through della directory di Microsoft Azure (Microsoft Entra ID).

Se un team dell'applicazione dati esegue l'onboarding di un asset dati riservato o inferiore , i nomi delle entità utente e gli oggetti entità servizio possono essere aggiunti a due gruppi di Microsoft Entra (uno per l'accesso in lettura/scrittura e l'altro per l'accesso in sola lettura). Questi due gruppi di Microsoft Entra devono essere creati durante il processo di onboarding e ordinati nella cartella del prodotto dati appropriata con contenitori riservati o inferiori per i dati non elaborati e arricchiti.

Questo modello consente a qualsiasi prodotto di calcolo che supporta l'autenticazione pass-through di Microsoft Entra per connettersi al data lake e autenticare gli utenti connessi. Se un utente fa parte del gruppo Microsoft Entra dell'asset di dati, può accedere ai dati tramite l'autenticazione pass-through di Microsoft Entra. Gli utenti all'interno del gruppo possono leggere l'intero asset di dati senza filtri dei criteri. È quindi possibile controllare in dettaglio l'accesso con i log appropriati e Microsoft Graph.

Per consigli sul layout del data lake, vedere Effettuare il provisioning di tre account Azure Data Lake Archiviazione Gen2 per ogni zona di destinazione dei dati.

Nota

Esempi di prodotti di calcolo sono Azure Databricks, Azure Synapse Analytics, Apache Spark e pool on demand di Azure Synapse SQL abilitati con l'autenticazione pass-through di Microsoft Entra.

Dati sensibili (dati personali)

Per i dati sensibili (dati personali), l'azienda deve limitare ciò che gli utenti possono visualizzare tramite criteri, copie dei dati o calcolo. In questo caso, l'organizzazione deve valutare l'opportunità di spostare o inserire il controllo di accesso nel livello di calcolo. Sono disponibili quattro opzioni per la protezione dei dati all'interno dell'analisi su scala cloud.

Scenario di esempio

L'esempio seguente descrive le opzioni per la protezione dei dati sensibili (dati personali):

Un'applicazione dati inserisce un prodotto di dati delle risorse umane (HR) per America del Nord ed Europa. Il caso d'uso prevede che gli utenti in Europa possano visualizzare solo i record del personale europeo e gli utenti in Nord America quelli del personale nordamericano. È ulteriormente limitato in modo che solo i manager delle risorse umane possano vedere le colonne contenenti i dati relativi alla retribuzione.

Le prime due opzioni offrono un modo per gestire dati sensibili (dati personali) e concedono anche il controllo ai team che si occupano di operazioni di integrazione e prodotti dati per identificare e limitare l'accesso. Potrebbe essere sufficiente per una piattaforma di analisi su piccola scala, ma un motore di criteri deve essere inserito nella zona di destinazione di gestione dei dati per un'azienda di grandi dimensioni con centinaia di prodotti dati. I motori dei criteri supportano una modo centralizzato per gestire, proteggere e controllare:

  • Accesso ai dati
  • Gestione del ciclo di vita dei dati
  • Regolamenti e criteri interni ed esterni
  • Criteri di condivisione dei dati
  • Identificazione dei dati sensibili (dati personali)
  • Informazioni dettagliate su protezione e conformità
  • Criteri per la creazione di report sulla protezione dei dati

In genere, un motore dei criteri si integra con un catalogo dati come Azure Purview. Azure Marketplace include soluzioni di terze parti e alcuni fornitori lavorano con Azure Synapse e Azure Databricks per crittografare e decrittografare le informazioni, fornendo allo stesso tempo la sicurezza a livello di riga e di colonna. A partire da gennaio 2022, Azure Purview ha lanciato un'anteprima pubblica per i criteri di accesso per controllare l'accesso ai dati archiviati in BLOB e Azure Data Lake Archiviazione (ADLS) Gen2. Vedere Provisioning del set di dati da parte del proprietario per Archiviazione di Azure (anteprima).

Il motore dei criteri deve usare i gruppi di Microsoft Entra per applicare criteri ai prodotti dati. Da qualsiasi soluzione di criteri che fornisce la privacy dei dati ci si aspetta la tokenizzazione dei dati sensibili (dati personali ) e la verifica costante tramite il controllo di accesso degli attributi, in modo che l'utente possa detokenizzare le colonne a cui deve accedere.

Come accennato, affinché un motore dei criteri abbia successo, è importante che si integri nel catalogo dati e che DevOps usi un'API REST per eseguire l'onboarding di un nuovo set di dati. Poiché i team dell'applicazione dati creano origini dati di lettura, vengono registrati nel catalogo dati e consentono di identificare i dati sensibili (dati personali). Il motore dei criteri deve importare la definizione e negare l'accesso ai dati fino a quando i team non hanno configurato i criteri di accesso. Tutto questo dovrebbe avvenire tramite un flusso di lavoro API REST della soluzione di gestione dei servizi IT.

Opzione 2: Versioni riservate o successive e sensibili (dati personali)

Per ogni prodotto dati classificato come dati sensibili (dati personali) vengono create dalla pipeline due copie. Uno classificato come riservato o inferiore con tutte le colonne sensibili (dati personali) rimosse e viene creato nella cartella riservato o seguente per il prodotto dati. L'altra copia viene creata nella cartella sensibile (dati personali) per il prodotto dati, che include tutti i dati sensibili. A ogni cartella viene assegnato un gruppo di sicurezza del lettore Microsoft Entra reader e un gruppo di sicurezza Microsoft Entra writer. L'uso di Gestione accesso ai dati può richiedere l'accesso al prodotto dati.

Sebbene ciò soddisfi la separazione dei dati sensibili (dati personali) e riservati o inferiori, un utente ha concesso l'accesso tramite l'autenticazione pass-through di Active Directory ai dati sensibili (dati personali) potrebbe eseguire query su tutte le righe. Se è necessaria la sicurezza a livello di riga, è necessario usare l'opzione 1: motore dei criteri (scelta consigliata) o opzione 3: database SQL di Azure, Istanza gestita di SQL o pool SQL di Azure Synapse Analytics.

Opzione 3: database SQL di Azure, Istanza gestita di SQL o pool SQL di Azure Synapse Analytics

Un'applicazione dati usa database SQL, Istanza gestita di SQL o pool SQL di Azure Synapse Analytics per caricare i prodotti dati in un database che supporta la sicurezza a livello di riga, la sicurezza a livello di colonna e la maschera dati dinamica. I team dell'applicazione dati creano diversi gruppi di Microsoft Entra e assegnano autorizzazioni che supportano la riservatezza dei dati.

Per questo caso d'uso, i team dell'applicazione dati devono creare i quattro gruppi di Microsoft Entra seguenti con accesso in sola lettura:

Raggruppa Autorizzazione
DA-AMERICA-HRMANAGER-R Visualizzare l'asset di dati del personale HR in America del Nord con informazioni sulla retribuzione.
DA-AMERICA-HRGENERAL-R Visualizzare l'asset di dati del personale HR in America del Nord senza informazioni sulla retribuzione.
DA-EUROPE-HRMANAGER-R Visualizzare l'asset di dati del personale HR in Europa con informazioni sulla retribuzione.
DA-EUROPE-HRGENERAL-R Visualizzare l'asset di dati del personale HR in Europa senza informazioni sulla retribuzione.

Il primo livello di restrizioni supporterebbe la maschera dati dinamica, che nasconde i dati sensibili agli utenti che non dispongono dei privilegi. Uno dei vantaggi di questo approccio è che può essere integrato nell'onboarding di un set di dati con un'API REST.

Il secondo livello aggiunge la sicurezza a livello di colonna per impedire ai manager non HR di visualizzare le retribuzioni e la sicurezza a livello di riga per limitare le righe che i membri dei team in Europa e America del Nord possono visualizzare.

Oltre alla crittografia dei dati trasparente, il livello di sicurezza sarebbe quello di crittografare la colonna di dati e decrittografarla al momento della lettura.

Le tabelle possono essere messe a disposizione di Azure Databricks con il connettore Apache Spark: SQL Server e database SQL di Azure.

Opzione 4: Azure Databricks

L'opzione 4 consiste nell'usare Azure Databricks per esplorare dati sensibili (dati personali). L'uso di una combinazione di librerie di crittografia Fernet, funzioni definite dall'utente, segreti di Databricks, controllo di accesso alle tabelle e funzioni di visualizzazione dinamica consente di crittografare e decrittografare le colonne.

Come descritto nel post di blog sull'applicazione della crittografia a livello di colonna per evitare la duplicazione dei dati:

Il primo passaggio di questo processo consiste nel proteggere i dati crittografandoli durante l'inserimento e una possibile soluzione è la libreria Python Fernet. Fernet usa la crittografia simmetrica, basata su diverse primitive crittografiche standard. Questa libreria viene usata all'interno di una funzione definita dall'utente per la crittografia che consentirà di crittografare una determinata colonna in un frame di dati. Per archiviare la chiave di crittografia, vengono usati i segreti di Databricks con controlli di accesso per consentire l'accesso solo al processo di inserimento dati. Dopo aver scritto i dati nelle tabelle Delta Lake, le colonne di dati personali che contengono valori come codice fiscale, numero di telefono, numero di carta di credito e altri identificatori non saranno più leggibili da parte di un utente non autorizzato.

Dopo aver scritto e protetto i dati sensibili, occorre un modo per consentire agli utenti con privilegi di leggerli. La prima cosa da fare è creare una funzione definita dall'utente permanente da aggiungere all'istanza di Hive in esecuzione in Databricks. Per essere permanente, una funzione definita dall'utente deve essere scritta in Scala. A questo scopo, Fernet dispone anche di un'implementazione Scala che è possibile usare per le letture decrittografate. Questa funzione definita dall'utente accede allo stesso segreto usato nella scrittura crittografata per eseguire la decrittografia e, in questo caso, viene aggiunta alla configurazione Spark del cluster. Questo richiede l'aggiunta di controlli di accesso al cluster per gli utenti con e senza privilegi per controllare il loro accesso alla chiave. Dopo aver creato la funzione definita dall'utente, è possibile usarla all'interno delle definizioni di visualizzazione per consentire agli utenti con privilegi di visualizzare i dati decrittografati.

Con le funzioni di visualizzazione dinamica è possibile creare una sola visualizzazione e restituire i valori crittografati o decrittografati in base al gruppo di Databricks di cui fanno parte.

Nell'esempio precedente si creano due funzioni di visualizzazione dinamica, una per l'America del Nord e un'altra per l'Europa, e si implementano le tecniche di crittografia in questo notebook.

Visualizzazione dell'America del Nord:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

Visualizzazione dell'Europa:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

Perché funzioni, è necessario abilitare il controllo di accesso alle tabelle di Azure Databricks nell'area di lavoro e applicare le autorizzazioni seguenti:

  • Concedere DA-AMERICA-HRMANAGER-R ai gruppi e DA-AMERICA-HRGENERAL-R Microsoft Entra l'accesso alla vhr_us visualizzazione.
  • Concedere DA-EUROPE-HRMANAGER-R ai gruppi e DA-EUROPE-HRGENERAL-R Microsoft Entra l'accesso alla vhr_eu visualizzazione.

Poiché le colonne sono crittografate e non possono essere decrittografate nell'area di lavoro riservata o successiva , le aree di lavoro riservate o seguenti possono comunque usare l'autenticazione pass-through di Microsoft Entra e consentire agli utenti di esplorare il lago, in base alle autorizzazioni.

Quando si usa l'accesso alle tabelle, i team che richiedono l'accesso vengono aggiunti all'area di lavoro di Azure Databricks. Azure Databricks userebbe le entità servizio per eseguire il mapping ad Azure Data Lake Storage, ma i dati verrebbero protetti con il controllo di accesso alle tabelle di Azure Databricks.

Man mano che vengono distribuiti nuovi prodotti dati, parte del processo DevOps dovrà eseguire script per configurare le autorizzazioni di tabella nell'area di lavoro di Azure Databricks e aggiungere i gruppi di Microsoft Entra corretti a tali autorizzazioni.

Nota

Il controllo di accesso alle tabelle di Azure Databricks non può essere combinato con l'autenticazione pass-through di Microsoft Entra. Pertanto, è possibile usare solo un'area di lavoro di Azure Databricks e usare invece il controllo di accesso alle tabelle.

Dati con restrizioni

Oltre all'implementazione di opzioni per i dati riservati o limitati, è consigliabile ospitare dati estremamente riservati in una zona di destinazione dei dati dedicata e in una zona di destinazione dei dati.

Consente requisiti specifici come l'accesso just-in-time, le chiavi gestite dal cliente per la crittografia e le restrizioni in ingresso o in uscita applicate alla zona di destinazione. Le indicazioni hanno valutato l'inserimento dei dati di questo tipo nella stessa zona di destinazione dei dati, ma in account di archiviazione diversi. Questo, tuttavia, può complicare la soluzione a livello di rete, ad esempio con i gruppi di sicurezza di rete e altri.

La zona di destinazione dedicata per la gestione dei dati con restrizioni deve connettersi al catalogo dei dati nella zona di destinazione dei dati "con restrizioni". Deve limitare gli utenti che possono cercare questi dati nel catalogo.

Passaggi successivi