Questo documento descrive l'utilizzo di Sensitive Data Protection per ridurre il rischio di esporre agli utenti i dati sensibili archiviati nei database di Google Cloud, pur consentendo loro di eseguire query su dati significativi.
All'interno dell'azienda possono essere presenti dati sensibili. I dati raccolti, elaborati e condivisi possono contenere informazioni, come informazioni che consentono l'identificazione personale (PII), soggette a norme o normative esterne e interne. Oltre agli adeguati controlli di sicurezza per limitare l'accesso ai dati sensibili, puoi utilizzare queste tecniche per proteggere i dati in uso. L'anonimizzazione aiuta a trovare un equilibrio tra utilità e privacy dei dati utilizzando tecniche quali mascheramento dei dati, bucketing e tokenizzazione.
La tokenizzazione sostituisce i dati sensibili con valori surrogati denominati token, che rappresentano il valore sensibile originale (non elaborato) quando i dati vengono sottoposti a query o visualizzati. Questo processo è a volte indicato come pseudonimizzazione o sostituzione surrogata. Il concetto di tokenizzazione è ampiamente utilizzato in settori come la finanza e la sanità, per ridurre il rischio dei dati in uso, ridurre l'ambito di conformità e minimizzare l'esposizione dei dati sensibili a persone o sistemi che non ne hanno bisogno.
Con Sensitive Data Protection puoi classificare e anonimizzare i dati sensibili in batch e in tempo reale. La classificazione è il processo di identificazione delle informazioni sensibili e della scelta del tipo. Il presente documento illustra dove è possibile utilizzare queste tecniche di anonimizzazione e mostra come utilizzare un proxy per eseguire queste attività.
Il seguente diagramma illustra lo scenario descritto in questo documento.
- I dati inattivi sono archiviati in Cloud Storage. Ad esempio, i dati ricevuti da un partner.
- I dati vengono importati tramite un processo di estrazione, trasformazione e caricamento (ETL) in un database SQL.
- Gli utenti eseguono query sui dati di questo database affinché eseguano l'analisi.
In questo scenario, i risultati restituiti dalla query sono dati non elaborati, quindi vengono visualizzati dati sensibili e potrebbero esporre i dati PII all'utente che esegue la query. Devi progettare la tua applicazione in modo da eseguire controlli e impedire query non autorizzate su dati sensibili.
L'architettura del proxy DLP
Un modo per proteggere i dati PII è passare tutte le query e i risultati tramite un servizio che analizza, ispeziona e quindi registra i risultati o li anonimizza utilizzando Sensitive Data Protection prima di restituire i dati richiesti all'utente. In questo documento, questo servizio è denominato proxy DLP.
L'applicazione proxy DLP accetta una query SQL come input, la esegue sul database, quindi applica la protezione dei dati sensibili ai risultati prima di restituirla all'utente che richiede i dati.
Il seguente diagramma illustra l'architettura dell'applicazione proxy DLP.
Sensitive Data Protection consente di configurare in modo dettagliato i tipi di dati da esaminare e come trasformare questi dati in base ai risultati dell'ispezione o alla struttura dei dati (ad esempio, i nomi dei campi). Per semplificare la creazione e la gestione della configurazione, puoi utilizzare i modelli di Sensitive Data Protection. L'applicazione proxy DLP fa riferimento ai modelli di inspect e anonimizzazione.
Puoi utilizzare i modelli per creare e conservare le informazioni di configurazione con Sensitive Data Protection. I modelli sono utili per disaccoppiare le informazioni di configurazione, ad esempio gli elementi da ispezionare e il modo in cui le anonimizza, dall'implementazione delle richieste. Per ulteriori informazioni sui modelli, consulta i modelli di Sensitive Data Protection.
Cloud Audit Logs è un servizio di logging integrato di Google Cloud usato in questa architettura. In primo luogo, Cloud Audit Logs fornisce un audit trail delle chiamate effettuate all'API Cloud Data Loss Prevention (parte di Sensitive Data Protection). Le voci dell'audit log includono informazioni su chi ha effettuato la chiamata API, su quale progetto Google Cloud è stata eseguita e dettagli sulla richiesta, incluso se un modello è stato utilizzato come parte della richiesta. In secondo luogo, se utilizzi il file di configurazione dell'applicazione per attivare il controllo, Cloud Audit Logs registra un riepilogo dei risultati dell'ispezione.
Cloud Key Management Service (Cloud KMS) è un servizio di gestione delle chiavi ospitato nel cloud di Google Cloud che consente di gestire le chiavi di crittografia per i servizi cloud.
I metodi di protezione dei dati sensibili per la tokenizzazione e lo variazione delle date utilizzano la crittografia per generare valori sostitutivi. Questi metodi crittografici utilizzano una chiave per criptare i valori in modo coerente al fine di mantenere l'integrità referenziale o, nel caso di metodi reversibili, per detokenizzare. Puoi fornire questa chiave direttamente a Sensitive Data Protection quando viene effettuata la chiamata oppure puoi eseguirne il wrapping utilizzando Cloud KMS. L'inclusione della chiave in Cloud KMS fornisce un ulteriore livello di controllo e controllo degli accessi ed è pertanto il metodo preferito per i deployment di produzione.
In una configurazione di produzione, devi utilizzare il principio del privilegio minimo per assegnare le autorizzazioni. Il seguente diagramma illustra un esempio di questo principio.
Il diagramma precedente mostra come in una configurazione di produzione tipica ci siano tre utenti tipo con ruoli diversi e accesso ai dati non elaborati:
- Amministratore dell'infrastruttura: installa e configura il proxy in modo che abbia accesso all'ambiente di computing in cui è installato il proxy Sensitive Data Protection.
Analista di dati: accede al client che si connette al proxy DLP.
Amministratore della sicurezza: classifica i dati, crea i modelli di Sensitive Data Protection e configura Cloud KMS.
Per ulteriori informazioni sull'utilizzo di Cloud KMS per criptare e decriptare i dati, consulta Crittografia e decriptazione dei dati.
Per il proxy DLP utilizzato in questo documento, queste informazioni sono tutte configurate in un modello di anonimizzazione per la protezione dei dati sensibili.
Protezione delle PII con controllo, mascheramento e tokenizzazione
Esistono due strategie che puoi implementare per ridurre il rischio di esposizione delle PII in questo scenario.
Dati non elaborati archiviati nel database
Se la tua applicazione archivia dati non elaborati in un database, puoi utilizzare il proxy DLP per elaborare i risultati restituiti all'utente mediante l'ispezione automatica e la generazione di un controllo di eventuali risultati sensibili. Oppure puoi mascherare i risultati in tempo reale, come illustrato nel diagramma seguente.
Per questa configurazione è necessario utilizzare un client SQL che si connette al proxy DLP. Se abiliti il controllo sull'app, in Cloud Audit Logs viene creato un log con un riepilogo dei risultati dell'ispezione. Questo riepilogo indica il tipo di informazioni sensibili restituite nella query.
Dati archiviati in forma anonimizzata
Se non vuoi archiviare i dati non elaborati, puoi archiviare i dati per la tua applicazione in un formato anonimizzato o mascherato eseguendo la trasformazione di anonimizzazione durante il processo ETL nel database, come illustrato nel diagramma seguente.
Il diagramma precedente illustra il flusso di base, in cui i dati vengono ispezionati e mascherati prima di essere importati nel database. Quando un utente esegue una query su questi dati, anche se ha accesso non elaborato al database, può vedere solo la versione mascherata.
Se consenti agli utenti di visualizzare i dati non mascherati, devi utilizzare un client in grado di connettersi a un'istanza del proxy DLP che disponga dell'autorizzazione per smascherare i dati, come illustrato nel diagramma seguente.
Il diagramma precedente illustra come utilizzare un client per connettersi al proxy DLP e consentire di mostrare al client i dati non mascherati.
Passaggi successivi
- Assumi il controllo dei tuoi dati: in che modo la tokenizzazione rende i dati utilizzabili senza sacrificare la privacy.
Esplora la seguente documentazione tecnica di Sensitive Data Protection:
Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.