Anonimizzazione e reidentificazione delle PII in set di dati su larga scala utilizzando Sensitive Data Protection

Last reviewed 2024-06-07 UTC

Questo documento illustra come utilizzare Sensitive Data Protection per creare una pipeline di trasformazione dei dati automatizzata per anonimizzare i dati sensibili come le informazioni che consentono l'identificazione personale (PII). Le tecniche di anonimizzazione come la tokenizzazione (assegnazione di pseudonimi) ti consentono di preservare l'utilità dei tuoi dati per le unioni o le analisi, riducendo al contempo il rischio di manipolare i dati offuscando gli identificatori di dati sensibili non elaborati. Per ridurre al minimo il rischio di gestire grandi volumi di dati sensibili, puoi utilizzare una pipeline di trasformazione dei dati automatizzata per creare di repliche anonimizzate. Protezione dei dati sensibili consente trasformazioni come oscuramento, mascheramento, tokenizzazione, bucket e altri metodi di anonimizzazione. Quando un set di dati non è stato caratterizzato, Sensitive Data Protection può anche ispezionare i dati per rilevare informazioni sensibili utilizzando più di 100 classificatori integrati.

Questo documento è rivolto a un pubblico tecnico le cui responsabilità che includano la sicurezza dei dati, il loro trattamento o l'analisi dei dati. Questa guida presuppone che tu abbia familiarità con il trattamento dei dati e la privacy dei dati, senza dover essere un esperto.

Architettura di riferimento

Il seguente diagramma mostra un'architettura di riferimento per l'utilizzo Prodotti Google Cloud per aggiungere un livello di sicurezza ai set di dati sensibili utilizzando tecniche di anonimizzazione.

Architettura della pipeline di anonimizzazione, della gestione della configurazione e della pipeline di reidentificazione.

L'architettura è costituita da quanto segue:

  • Pipeline di flusso per l'anonimizzazione dei dati: anonimizza i dati sensibili i dati in testo utilizzando Dataflow. Puoi riutilizzare la pipeline per più trasformazioni e casi d'uso.

  • Gestione della configurazione (modello e chiave di Sensitive Data Protection): una configurazione gestita di anonimizzazione accessibile solo a un piccolo gruppo di persone, ad esempio gli amministratori della sicurezza, per evitare di esporre l'anonimizzazione metodi e chiavi di crittografia.

  • Pipeline di convalida e reidentificazione dei dati: convalida le copie dei i dati anonimizzati e utilizza una pipeline Dataflow per a reidentificare i dati su larga scala.

Contribuire a proteggere i dati sensibili

Una delle attività chiave di qualsiasi azienda è contribuire a garantire la sicurezza dei dati degli utenti e dei dipendenti. Google Cloud offre sicurezza integrata misure per facilitare la sicurezza dei dati, tra cui la crittografia dei dati archiviati e la crittografia dei dati in transito.

Crittografia dei dati inattivi: Cloud Storage

Mantenere la sicurezza dei dati è fondamentale per la maggior parte delle organizzazioni. Non autorizzato l'accesso a dati anche moderatamente sensibili può danneggiare l'affidabilità, e la tua reputazione presso i tuoi clienti. Google cripta i dati archiviati at-rest per impostazione predefinita. Per impostazione predefinita, qualsiasi oggetto caricato Cloud Storage è criptato tramite Chiave di proprietà di Google e gestita da Google. Se il tuo set di dati utilizza un metodo di crittografia preesistente e richiede un'opzione diversa da quella predefinita prima del caricamento, esistono altre opzioni di crittografia fornite da Cloud Storage. Per ulteriori informazioni, vedi Opzioni di crittografia dei dati.

Crittografia dei dati in transito: Dataflow

Quando i dati sono in transito, la crittografia at-rest non è attiva. I dati in transito sono protetti da protocolli di rete sicuri denominati crittografia in transito. Per impostazione predefinita, Dataflow utilizza chiavi di proprietà e gestite da Google. I tutorial associati a questo documento utilizzano una pipeline automatica che utilizza le chiavi predefinite di proprietà di Google e gestite da Google.

Trasformazioni dei dati di Sensitive Data Protection

Esistono due tipi principali di trasformazioni eseguite da Sensitive Data Protection:

Entrambi i metodi recordTransformations e infoTypeTransformations possono anonimizza e cripta le informazioni sensibili nei tuoi dati. Ad esempio, puoi trasforma i valori nella colonna US_SOCIAL_SECURITY_NUMBER in modo che non identificabili o utilizzare la tokenizzazione per nasconderla, mantenendo al contempo dei dati.

Il metodo infoTypeTransformations ti consente di verificare la presenza di dati sensibili e di trasformare il risultato. Ad esempio, se hai dati non strutturati o di testo libero, il metodo infoTypeTransformations può aiutarti a identificare un SSN all'interno di una frase e criptare il valore SSN lasciando invariato il resto del testo. Puoi anche definire metodi infoTypes personalizzati.

Il metodo recordTransformations ti consente di applicare una configurazione di trasformazione per campo quando utilizzi dati strutturati o tabulari. Con il metodo recordTransformations, puoi applicare la stessa trasformazione a ogni valore del campo, ad esempio l'hashing o la tokenizzazione di ogni valore di una colonna con la colonna recordTransformations come nome del campo o dell'intestazione.

Con il metodo recordTransformations , puoi anche combinare Metodo infoTypeTransformations che si applica solo ai valori nell'attributo specificato campi. Ad esempio, puoi utilizzare un metodo infoTypeTransformations all'interno di un Metodo recordTransformations per il campo denominato comments per oscurare eventuali risultati relativi a US_SOCIAL_SECURITY_NUMBER che si trovano all'interno del testo .

In un ordine di complessità sempre più complesso, i processi di anonimizzazione sono che segue:

  • Oscuramento: rimuovi i contenuti sensibili senza sostituire quelli.
  • Mascheramento: sostituisci i contenuti sensibili con caratteri fissi.
  • Crittografia: sostituisci i contenuti sensibili con stringhe criptate, possibilmente in modo reversibile.

Lavorare con dati delimitati

Spesso, i dati sono costituiti da record delimitati da un carattere selezionato, con tipi di riga di comando in ogni colonna, come un file CSV. Per questa classe di dati, puoi applicare direttamente le trasformazioni di spersonalizzazione (recordTransformations) senza ispezionare i dati. Ad esempio, puoi aspettarti una colonna con l'etichetta SSN contenere solo dati SSN. Non è necessario ispezionare i dati per sapere che il rilevatoreinfoType è US_SOCIAL_SECURITY_NUMBER. Tuttavia, i video in formato libero Le colonne con l'etichetta Additional Details possono contenere informazioni sensibili, ma le Il corso infoType è sconosciuto in anticipo. Per una colonna in formato libero, devi esaminare il rilevatore infoTypes (infoTypeTransformations) prima di applicare le trasformazioni di anonimizzazione. Sensitive Data Protection consente tipi di trasformazione per coesistere in un singolo modello di anonimizzazione. Sensitive Data Protection include più di 100 rilevatori infoTypes integrati. Puoi anche creare tipi personalizzati o modificare i rilevatori infoTypes integrati in a trovare dati sensibili univoci per la tua organizzazione.

Determinazione del tipo di trasformazione

La scelta del momento in cui utilizzare il metodo recordTransformations o infoTypeTransformations dipende dal caso d'uso. Poiché l'utilizzo di infoTypeTransformations richiede più risorse e, pertanto, è più costoso, consigliamo di utilizzare questo metodo solo nelle situazioni in cui il tipo di dati non è noto. Puoi valutare i costi di esecuzione della Protezione dei dati sensibili utilizzando il Calcolatore prezzi di Google Cloud.

Per esempi di trasformazione, questo documento fa riferimento a un set di dati che contiene File CSV con colonne fisse, come illustrato nella tabella seguente.

Nome colonna Ispezione infoType (personalizzata o integrata) Tipo di trasformazione di Sensitive Data Protection
Card Number Non applicabile Crittografia deterministica (DE)
Card Holder's Name Non applicabile Crittografia deterministica (DE)
Card PIN Non applicabile Crypto hashing
SSN (Social Security Number) Non applicabile Mascheramento
Age Non applicabile Bucketing
Job Title Non applicabile Bucketing
Additional Details Integrata:
IBAN_CODE, EMAIL_ADDRESS PHONE_NUMBER
Personalizza:
ONLINE_USER_ID 		Sostituzione

Questa tabella elenca i nomi delle colonne e descrive il tipo di trasformazione necessari per ogni colonna. Ad esempio, la colonna Card Number contiene il merito numeri di carte che devono essere crittografati; ma non è necessario viene ispezionato perché il tipo di dati (infoType) è noto.

L'unica colonna in cui è consigliata una trasformazione di ispezione è la colonna Additional Details. Questa colonna è in formato libero e può contenere PII, che, ai fini di questo esempio, dovrebbero essere rilevate e anonimizzate.

Gli esempi in questa tabella presentano cinque diverse trasformazioni di anonimizzazione:

  • Tokenizzazione bidirezionale: sostituisce i dati originali con un token deterministica e preservare l'integrità referenziale. Puoi utilizzare il token unire i dati o utilizzare il token nell'analisi aggregata. Puoi invertire o detokenizzare i dati utilizzando la stessa chiave utilizzata per creare il token. Esistono due metodi per la tokenizzazione bidirezionale:

    • Crittografia deterministica (DE): sostituisce i dati originali con un valore criptato con codifica Base64 e non conserva il set di caratteri o la lunghezza originali.
    • Crittografia con protezione del formato con FFX (FPE-FFX): Sostituisce i dati originali con un token generato utilizzando con protezione del formato in modalità FFX. Per impostazione predefinita, FPE-FFX conserva la lunghezza e il set di caratteri del testo inserito. Manca l'autenticazione e un vettore di inizializzazione, il che può causare un aumento della lunghezza nel token di output. Altri metodi, come la DE, offrono una maggiore sicurezza e sono consigliati per i casi d'uso di tokenizzazione, a meno che la lunghezza e la conservazione dei set di caratteri non siano requisiti rigidi, come la compatibilità con i sistemi di dati legacy.

  • Tokenizzazione unidirezionale mediante hashing criptato: sostituisce il valore originale con un valore sottoposto ad hashing, preservando l'integrità referenziale. Tuttavia, a differenza della tokenizzazione bidirezionale, un metodo unidirezionale non è reversibile. Il valore hash viene generato utilizzando un codice di autenticazione dei messaggi basato su SHA-256 (HMAC-SHA-256) sul valore di input.

  • Mascheramento: sostituisce i dati originali con un carattere specificato, parzialmente o completamente.

  • Bucketing: sostituisce un valore più identificabile con un valore meno distintivo.

  • Sostituzioni: sostituisce i dati originali con un token o il nome del infoType se rilevato.

Selezione del metodo

La scelta del metodo di anonimizzazione migliore può variare in base al caso d'uso. Ad esempio, se un'app precedente elabora i record anonimizzati, la conservazione del formato potrebbe essere importante. Se hai a che fare con formati rigorosamente numeri a 10 cifre, FPE conserva la lunghezza (10 cifre) e il set di caratteri (numerico) di un input per il supporto di sistemi precedenti.

Tuttavia, se per la compatibilità precedente non è necessaria una formattazione rigida, così come per i valori nella colonna Card Holder's Name, allora DE è il è la scelta preferita perché ha un metodo di autenticazione più forte. Sia la crittografia lato client sia la decrittografia consentono di annullare o decodificare i token. Se non ti serve la de-tokenizzazione, l'hashing crittografico fornisce l'integrità, ma i token è irreversibile.

Altri metodi, come il mascheramento, il bucketing, lo spostamento della data e la sostituzione, sono adatti per i valori che non devono mantenere la piena integrità. Ad esempio, suddividere in bucket un valore di età (ad es. 27) in una fascia d'età (20-30) può essere ancora analizzato, riducendo al contempo l'univocità che potrebbe l'identificazione di un individuo.

Chiavi di crittografia dei token

Per le trasformazioni di anonimizzazione crittografica, è necessaria una chiave di crittografia, nota anche come chiave di crittografia del token. La chiave di crittografia del token utilizzata per la crittografia di anonimizzazione viene utilizzata anche per reidentificare valore originale. La creazione e la gestione sicure delle chiavi di crittografia dei token che esulano dall'ambito di applicazione del presente documento. Tuttavia, esistono alcuni principi importanti da considerare, che verranno utilizzate in seguito nei tutorial associati:

  • Evita di utilizzare chiavi di testo non crittografato nel modello. Utilizza invece Cloud KMS per creare una chiave con wrapping.
  • Utilizza chiavi di crittografia dei token separate per ogni elemento di dati al fine di ridurre il rischio di compromettere le chiavi.
  • Ruota di crittografia dei token. Sebbene tu possa ruotare la chiave con wrapping, la rotazione della chiave di crittografia del token ne compromette l'integrità. Quando la chiave viene ruotata, devi eseguire nuovamente la tokenizzazione dell'intero set di dati.

Modelli di Sensitive Data Protection

Per deployment su larga scala, usa Modelli di Sensitive Data Protection per eseguire le seguenti operazioni:

  • Attiva il controllo della sicurezza con Identity and Access Management (IAM).
  • Scollega le informazioni di configurazione e la modalità di anonimizzazione di queste informazioni dall'implementazione delle tue richieste.
  • Riutilizzare un insieme di trasformazioni. Puoi utilizzare i modelli di anonimizzazione e di identificazione su più set di dati.

BigQuery

Il componente finale dell'architettura di riferimento è la visualizzazione e l'utilizzo dei dati anonimizzati in BigQuery. BigQuery è lo strumento di data warehouse di Google che include dell'infrastruttura serverless, BigQuery ML e la capacità Sensitive Data Protection come strumento nativo. Nell'esempio di architettura di riferimento, BigQuery funge da data warehouse per i dati anonimizzati e da backend per una pipeline di dati di reidentificazione automatica che può condividere i dati tramite Pub/Sub.

Passaggi successivi