Questo documento descrive l'utilizzo della protezione dei dati sensibili per ridurre il rischio di esposizione agli utenti di dati sensibili archiviati nei database Google Cloud, continuando a consentire loro di eseguire query su dati significativi.
I dati sensibili possono esistere all'interno della tua azienda. 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 ai controlli di sicurezza appropriati per limitare l'accesso ai dati sensibili, puoi utilizzare queste tecniche anche per proteggere i dati in uso. L'anonimizzazione aiuta a trovare un equilibrio tra utilità e privacy dei dati utilizzando tecniche come mascheramento dei dati, bucket e tokenizzazione.
La tokenizzazione sostituisce i dati sensibili con valori surrogati chiamati token, che rappresentano il valore sensibile originale (non elaborato) quando i dati vengono sottoposti a query o visualizzati. Questo processo è talvolta definito pseudonimizzazione o sostituzione surrogata. Il concetto di tokenizzazione è ampiamente utilizzato in settori come la finanza e la sanità, per ridurre il rischio di utilizzo dei dati, ridurre l'ambito di conformità e ridurre al minimo 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 di determinazione del loro tipo. Questo documento illustra dove puoi utilizzare queste tecniche di anonimizzazione e mostra come utilizzare un proxy per svolgere queste attività.
Il seguente diagramma illustra lo scenario descritto in questo documento.
- I dati sono archiviati at-rest 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 in questo database per eseguire l'analisi.
In questo scenario, i risultati restituiti dalla query sono dati non elaborati, quindi i dati sensibili vengono visualizzati e possono potenzialmente esporre dati PII all'utente che esegue la query. Dovresti progettare l'applicazione in modo da controllare ed evitare 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 oppure anonimizza i risultati utilizzando Sensitive Data Protection prima di restituire i dati richiesti all'utente. In questo documento, il servizio è chiamato 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 ispezionare e come trasformarli 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, utilizza 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 mantenere le informazioni di configurazione con Sensitive Data Protection. I modelli sono utili per disaccoppiare le informazioni di configurazione, ad esempio gli elementi sottoposti a controllo e come anonimizzarli, dall'implementazione delle richieste. Per ulteriori informazioni sui modelli, consulta la pagina relativa ai modelli di Sensitive Data Protection.
Cloud Audit Logs è un servizio di logging integrato di Google Cloud utilizzato 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 il spostamento delle date utilizzano la crittografia per generare i 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 annullare la tokenizzazione. Puoi fornire questa chiave direttamente a Sensitive Data Protection quando viene effettuata la chiamata oppure puoi eseguire il wrapping utilizzando Cloud KMS. L'wrapping della chiave in Cloud KMS offre un ulteriore livello di controllo e controllo dell'accesso, perciò è il metodo preferito per i deployment in produzione.
In una configurazione di produzione, dovresti 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 tipica configurazione di produzione esistono 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 su cui è installato il proxy di Sensitive Data Protection.
Analista 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 di Sensitive Data Protection.
Protezione delle PII con audit, mascheramento e tokenizzazione
Esistono due strategie che puoi implementare per ridurre il rischio di esporre PII in questo scenario.
Dati non elaborati archiviati nel database
Se l'applicazione archivia dati non elaborati in un database, puoi utilizzare il proxy DLP per elaborare i risultati restituiti all'utente ispezionando e generando automaticamente un controllo di eventuali risultati sensibili. Oppure puoi mascherare i risultati della query in tempo reale, come illustrato nel seguente diagramma.
Questa configurazione richiede l'utilizzo di un client SQL che si connette al proxy DLP. Se abiliti il controllo nell'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 una forma anonimizzata o mascherata eseguendo le trasformazioni di anonimizzazione nel database durante il processo ETL, 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ò visualizzare solo la versione mascherata.
Se consenti all'utente di visualizzare i dati non mascherati, devi utilizzare un client in grado di connettersi a un'istanza del proxy DLP che dispone dell'autorizzazione per annullare la mascheratura dei dati, come illustrato nel diagramma seguente.
Il diagramma precedente mostra come utilizzare un client per la connessione al proxy DLP in modo da consentire la visualizzazione di dati non mascherati al client.
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.