Privacy dei dati per l'analisi su scala cloud in Azure
L'analisi su scala cloud consente di determinare i modelli di accesso ai dati ottimali che soddisfano i requisiti, salvaguardando i dati personali a più livelli. I dati personali includono tutte le informazioni che possono identificare in modo univoco le persone, ad esempio i numeri di licenza del conducente, i numeri di previdenza sociale, i dettagli del conto bancario, i numeri di passaporto e gli indirizzi di posta elettronica. Esistono molte normative per proteggere la privacy degli utenti.
Per proteggere la privacy dei dati all'interno di un ambiente cloud, ad esempio Azure, è possibile creare uno schema di riservatezza dei dati che specifica i criteri di accesso ai dati. Questi criteri possono definire l'architettura sottostante in cui risiede l'applicazione dati, definire come autorizzare l'accesso ai dati e specificare le righe o le colonne a cui gli utenti possono accedere.
Creare uno schema di classificazione della riservatezza dei dati
| Classificazione | Descrizione |
|---|---|
| Pubblico | 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 dati, è necessario classificare i dati come riservati o sotto o dati personali sensibili:
- Ordinare i dati in dati riservati o inferiori se non è necessario limitare le colonne e le righe che gli utenti possono visualizzare.
- Ordinare i dati in dati personali sensibili se è necessario limitare le colonne e le righe che gli utenti possono visualizzare.
Importante
Un set di dati può passare da riservato o inferiore a dati personali sensibili quando si combinano dati con altri prodotti dati che in precedenza avevano una classificazione inferiore. Se sono necessari dati persistenti, spostarli in una cartella designata allineata al livello di riservatezza e al processo di onboarding.
Creare un set di criteri di Azure
Dopo aver classificato i dati, è necessario allineare la classificazione ai requisiti dei criteri di settore e ai criteri aziendali interni. Si vuole creare un set di criteri di Azure che regola l'infrastruttura che può essere distribuita, il percorso in cui può essere distribuito e gli standard di rete e crittografia.
Per i settori regolamentati, è possibile usare le iniziative dei criteri di conformità alle normative di Microsoft come baseline per i framework di conformità.
La classificazione dei dati segue le stesse regole per la crittografia, gli SKU dell'infrastruttura consentiti e le iniziative politiche. È quindi possibile archiviare tutti i dati all'interno della stessa zona di destinazione.
Per i dati con restrizioni, è consigliabile ospitare i dati in una zona di destinazione dei dati dedicata in un gruppo di gestione in cui è possibile definire un set di requisiti più elevato per l'infrastruttura. Ad esempio, è possibile definire chiavi gestite dal cliente per la crittografia o le restrizioni in ingresso o in uscita per la zona di destinazione.
Nota
È possibile inserire dati personali sensibili e dati riservati o inferiori nella stessa zona di destinazione dei dati, ma account di archiviazione diversi. Questa procedura potrebbe tuttavia complicare la soluzione a livello di rete, ad esempio con i gruppi di sicurezza di rete.
Una soluzione di governance dei dati distribuita deve limitare chi può cercare dati con restrizioni nel catalogo. Prendere in considerazione l'implementazione dell'accesso condizionale di Microsoft Entra ID per tutti gli asset di dati e i servizi. Per migliorare la sicurezza, applicare l'accesso just-in-time per i dati riservati.
Prendere in considerazione i requisiti di crittografia
Oltre a definire criteri per le posizioni e i servizi di Azure consentiti, prendere in considerazione i requisiti di crittografia per ogni classificazione dei dati. Considerare i requisiti per le aree seguenti:
- Gestione delle chiavi
- Archiviazione delle chiavi
- Crittografia dei dati statici
- Crittografia dei dati in transito
- Crittografia dei dati in uso
Per la gestione delle chiavi, è possibile usare chiavi di crittografia gestite dalla piattaforma o gestite dal cliente. Per altre informazioni, vedere Panoramica della gestione delle chiavi in Azure e Come scegliere la soluzione di gestione delle chiavi appropriata.
Per altre informazioni sulle opzioni di crittografia, vedere Azure crittografia dei dati nello stato di inattività e modelli di crittografia dei dati.
È possibile usare il protocollo TLS (Transport Layer Security) per proteggere i dati che si spostano tra i servizi cloud e i clienti. Per altre informazioni, vedere Crittografia dei dati in transito.
Se lo scenario richiede che i dati rimangano crittografati durante l'uso, il modello di minaccia confidential computing di Azure consente di ridurre al minimo l'attendibilità. Riduce al minimo la possibilità che gli operatori del provider di servizi cloud o altri attori nel dominio del tenant possano accedere al codice e ai dati durante l'implementazione.
Per ulteriori informazioni, vedere i prodotti di Azure confidential computing.
Implementare la governance dei dati
Dopo aver definito i criteri per la distribuzione dei servizi di Azure consentiti, determinare come concedere l'accesso al prodotto dati.
Se si dispone di una soluzione di governance dei dati, ad esempio Microsoft Purview o Azure Databricks Unity Catalog, è possibile creare asset di dati o prodotti per livelli data lake arricchiti e curati. Assicurarsi di impostare le autorizzazioni all'interno del catalogo dati per proteggere tali oggetti dati.
Usare Microsoft Purview per gestire, proteggere e controllare centralmente le aree seguenti:
- Accesso ai dati
- Ciclo di vita dei dati
- Regolamenti e criteri interni ed esterni
- Criteri di condivisione dei dati
- Identificazione dei dati sensibili
- Informazioni dettagliate su protezione e conformità
- Criteri per la creazione di report sulla protezione dei dati
Per ulteriori informazioni su come utilizzare Microsoft Purview per gestire l'accesso in lettura o modifica, vedere Concepts for Microsoft Purview data owner policies.
Indipendentemente dal fatto che si decida di implementare Microsoft Purview o un'altra soluzione di governance dei dati, utilizzare i gruppi Microsoft Entra ID per applicare le policy ai prodotti di dati.
Usare l'API REST della soluzione di governance dei dati per eseguire l'onboarding di un nuovo set di dati. I team di applicazioni dati creano prodotti di dati e li registrano nella soluzione di governance dei dati per aiutare a identificare i dati sensibili. La soluzione di governance dei dati importa la definizione e nega l'accesso ai dati fino a quando i team non configurano i criteri di accesso.
Usare i modelli di protezione dei dati
Per proteggere i dati sensibili, scegliere un modello di protezione dei dati in base ai dati, ai servizi e ai criteri implementati.
Più copie
La pipeline per ogni prodotto di dati con una classificazione di dati personali sensibili crea due copie. La pipeline classifica il primo elemento come riservato o inferiore. Questa copia non include le colonne di dati personali sensibili. Viene creato nella cartella "confidential-or-below" per il prodotto di dati. L'altra copia viene creata nella cartella dati personali sensibili. Questa copia include i dati sensibili. A ogni cartella viene assegnato un lettore ID Microsoft Entra e un gruppo di sicurezza microsoft Entra ID writer.
Se si usa Microsoft Purview, è possibile registrare entrambe le versioni del prodotto dati e usare i criteri per proteggere i dati.
Il modello di copia multipla separa i dati personali sensibili e i dati riservati o inferiori. Tuttavia, se si concede a un utente l'accesso ai dati personali sensibili, è possibile eseguire query su tutte le righe. L'organizzazione potrebbe dover prendere in considerazione altre soluzioni che forniscono sicurezza a livello di riga per filtrare le righe.
Sicurezza a livello di riga e a livello di colonna
Se è necessario filtrare le righe che gli utenti possono visualizzare, è possibile spostare i dati in una soluzione di calcolo che usa la sicurezza a livello di riga.
Per evitare la ricompilazione, selezionare il servizio di Azure o la soluzione Microsoft Fabric appropriata per il caso d'uso specifico. Diversi tipi di database sono progettati per scopi diversi. Ad esempio, non è consigliabile usare un database OLTP (Online Transaction Processing) per un'analisi completa. Se si usa un'applicazione di e-commerce, non è consigliabile usare una soluzione personalizzata per l'analisi dei Big Data perché non è in grado di ottenere i tempi di risposta in millisecondi necessari.
Se si implementano soluzioni che supportano la sicurezza a livello di riga, i team dell'applicazione dati devono creare gruppi di ID Microsoft Entra diversi e assegnare autorizzazioni in base alla sensibilità dei dati.
Oltre alla sicurezza a livello di riga, è possibile limitare l'accesso a determinate colonne. La tabella seguente illustra un esempio di quattro gruppi di Microsoft Entra ID con accesso in sola lettura.
| Gruppo | Permesso |
|---|---|
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 supporta la maschera dati dinamica, che nasconde i dati sensibili agli utenti che non dispongono di privilegi. È possibile usare un'API REST per integrare questo approccio nell'onboarding di un set di dati.
Il secondo livello di restrizioni aggiunge la sicurezza a livello di colonna per impedire ai manager non delle risorse umane di visualizzare i salari. Aggiunge inoltre la sicurezza a livello di riga per limitare le righe che possono essere visualizzate dai membri del team europei e nordamericani.
Crittografia delle colonne
La maschera dati dinamica maschera i dati al momento della presentazione, ma alcuni casi d'uso richiedono che la soluzione non abbia mai accesso ai dati di testo non crittografato.
La funzionalità Always Encrypted di SQL migliora la sicurezza dei dati sensibili nei database di SQL Server. SQL Always Encrypted consente di garantire che i dati sensibili nei database di SQL Server rimangano protetti e protetti dall'accesso non autorizzato. Questa caratteristica crittografa i dati inattivi e in transito, aiutando a mantenere la massima riservatezza dei dati e la conformità alle normative. SQL Always Encrypted esegue operazioni di crittografia e decrittografia sul lato client. Integrare questa funzionalità per proteggere gli asset di dati più importanti.