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

Last reviewed 2022-08-11 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 (pseudonimizzazione) ti consentono di preservare l'utilità dei tuoi dati per l'unione o l'analisi, riducendo il rischio di gestione dei dati offuscando gli identificatori sensibili non elaborati. Per ridurre al minimo il rischio di gestire grandi volumi di dati sensibili, puoi utilizzare una pipeline di trasformazione automatica dei dati per creare repliche anonimizzate. Sensitive Data Protection consente trasformazioni come l'oscuramento, il mascheramento, la tokenizzazione, il bucketing e altri metodi di anonimizzazione. Se un set di dati non è stato caratterizzato, Sensitive Data Protection può anche esaminare i dati per individuare informazioni sensibili utilizzando più di 100 classificatori integrati.

Questo documento è destinato a un pubblico tecnico le cui responsabilità includono sicurezza, trattamento o analisi dei dati. Questa guida presuppone che tu abbia familiarità con il trattamento e la privacy dei dati, senza bisogno di essere esperti.

Architettura di riferimento

Il seguente diagramma mostra un'architettura di riferimento per l'utilizzo dei prodotti Google Cloud al fine di aggiungere un livello di sicurezza a set di dati sensibili utilizzando tecniche di anonimizzazione.

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

L'architettura è costituita da quanto segue:

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

  • Gestione della configurazione (chiave e modello di protezione dei dati sensibili): una configurazione di anonimizzazione gestita accessibile solo a un gruppo ristretto di utenti, ad esempio gli amministratori della sicurezza, per evitare di esporre metodi di anonimizzazione e chiavi di crittografia.

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

Contribuire a proteggere i dati sensibili

Una delle attività principali di ogni impresa è quella di garantire la sicurezza dei dati di utenti e dipendenti. Google Cloud fornisce misure di sicurezza integrate per facilitare la sicurezza dei dati, tra cui la crittografia dei dati archiviati e la crittografia dei dati in transito.

Crittografia at-rest: Cloud Storage

Mantenere la sicurezza dei dati è fondamentale per la maggior parte delle organizzazioni. L'accesso non autorizzato a dati anche moderatamente sensibili può danneggiare la fiducia, le relazioni e la reputazione che contraddistinguono i tuoi clienti. Google cripta i dati archiviati at-rest per impostazione predefinita. Per impostazione predefinita, qualsiasi oggetto caricato in un bucket Cloud Storage viene criptato tramite una chiave di crittografia gestita da Google. Se il set di dati utilizza un metodo di crittografia preesistente e richiede un'opzione non predefinita prima del caricamento, sono disponibili altre opzioni di crittografia fornite da Cloud Storage. Per ulteriori informazioni, consulta Opzioni di crittografia dei dati.

Crittografia dei dati in transito: Dataflow

Quando i tuoi dati sono in transito, la crittografia at-rest non è attiva. I dati in transito sono protetti da protocolli di rete sicuri indicati come crittografia in transito. Per impostazione predefinita, Dataflow utilizza le chiavi di crittografia gestite da Google. I tutorial associati a questo documento utilizzano una pipeline automatica che utilizza le chiavi di crittografia predefinite 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 anonimizzare e criptare le informazioni sensibili nei dati. Ad esempio, puoi trasformare i valori nella colonna US_SOCIAL_SECURITY_NUMBER in modo che siano uniformi o utilizzare la tokenizzazione per oscurarli mantenendo l'integrità referenziale.

Il metodo infoTypeTransformations consente di ispezionare dati sensibili e trasformare il risultato. Ad esempio, se disponi di dati non strutturati o in testo libero, il metodo infoTypeTransformations può aiutarti a identificare un codice fiscale all'interno di una frase e criptare il valore dell'SSN, lasciando intatto il resto del testo. Puoi anche definire metodi infoTypes personalizzati.

Il metodo recordTransformations 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 tutti i valori in un determinato campo, ad esempio eseguire l'hashing o la tokenizzazione di ogni valore in una colonna con colonna SSN come nome del campo o dell'intestazione.

Con il metodo recordTransformations , puoi anche combinare il metodo infoTypeTransformations che si applica solo ai valori nei campi specificati. 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 del campo.

In ordine crescente di complessità, i processi di anonimizzazione sono i seguenti:

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

Utilizzare i dati delimitati

Spesso, i dati sono costituiti da record delimitati da un carattere selezionato, con tipi fissi in ogni colonna, come un file CSV. Per questa classe di dati, puoi applicare direttamente le trasformazioni di anonimizzazione (recordTransformations), senza esaminare i dati. Ad esempio, una colonna con l'etichetta SSN potrebbe contenere solo dati dell'SSN. Non devi ispezionare i dati per sapere che il rilevatore infoType è US_SOCIAL_SECURITY_NUMBER. Tuttavia, le colonne in formato libero etichettate Additional Details possono contenere informazioni sensibili, ma la classe infoType è stata precedentemente sconosciuta. Per una colonna in formato libero, devi controllare il rilevatore infoTypes (infoTypeTransformations) prima di applicare le trasformazioni di anonimizzazione. Sensitive Data Protection consente a entrambi questi tipi di trasformazione di coesistere in un unico modello di anonimizzazione. Sensitive Data Protection include più di 100 rilevatori infoTypes integrati. Puoi anche creare tipi personalizzati o modificare i rilevatori infoTypes integrati per trovare dati sensibili univoci per la tua organizzazione.

Determinazione del tipo di trasformazione

La determinazione del momento in cui utilizzare i metodi recordTransformations o infoTypeTransformations dipende dal caso d'uso. Poiché l'utilizzo del metodo infoTypeTransformations richiede più risorse e, di conseguenza, è più costoso, consigliamo di utilizzarlo solo nelle situazioni in cui il tipo di dati è sconosciuto. Puoi valutare i costi dell'esecuzione di Sensitive Data Protection utilizzando il Calcolatore prezzi di Google Cloud.

Per esempi di trasformazione, questo documento si riferisce a un set di dati contenente file CSV con colonne fisse, come mostrato nella seguente tabella.

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 Hashing delle criptovalute
SSN (Social Security Number) Non applicabile Mascheramento
Age Non applicabile Bucket
Job Title Non applicabile Bucket
Additional Details Integrate:
IBAN_CODE, EMAIL_ADDRESS, PHONE_NUMBER
Personalizzata:
ONLINE_USER_ID
Sostituzione

Questa tabella elenca i nomi delle colonne e descrive il tipo di trasformazione necessario per ogni colonna. Ad esempio, la colonna Card Number contiene numeri di carte di credito che devono essere criptati, ma non devono essere ispezionati, 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 potrebbe contenere PII che, ai fini di questo esempio, devono essere rilevate e anonimizzate.

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

  • Tokenizzazione bidirezionale: sostituisce i dati originali con un token deterministico, che preserva l'integrità referenziale. Puoi utilizzare il token per unire i dati o utilizzarlo nell'analisi aggregata. Puoi annullare o annullare la tokenizzazione dei 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 la lunghezza o il set di caratteri originali.
    • Crittografia con protezione del formato con FFX (FPE-FFX): sostituisce i dati originali con un token generato utilizzando la crittografia con protezione del formato in modalità FFX. FPE-FFX è progettato in modo da preservare la lunghezza e il set di caratteri del testo di input. Manca l'autenticazione e un vettore di inizializzazione, il che può causare un'espansione della lunghezza nel token di output. Altri metodi, come la DE, forniscono una sicurezza più efficace e sono consigliati per i casi d'uso di tokenizzazione, a meno che la lunghezza e la conservazione del set di caratteri non siano requisiti rigorosi, come la compatibilità con i sistemi di dati legacy.
  • Tokenizzazione unidirezionale, con hashing di crittografia: 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.

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

  • Sostituzione: sostituisce i dati originali con un token o con il nome infoType, se rilevati.

Selezione del metodo

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

Tuttavia, se per la compatibilità precedente non è richiesta una formattazione rigorosa, come per i valori nella colonna Card Holder's Name, DE è la scelta preferita perché offre un metodo di autenticazione più efficace. Sia FPE che DE consentono di invertire o annullare la tokenizzazione dei token. Se non hai bisogno della de-tokenizzazione, l'hashing della crittografia fornisce l'integrità, ma i token non possono essere annullati.

Altri metodi, come mascheramento, bucket, date-shifting e sostituzione, sono adatti per i valori che non devono mantenere la piena integrità. Ad esempio, è comunque possibile analizzare un bucket di un valore relativo all'età (ad esempio 27) a una fascia d'età (20-30) riducendo al contempo l'unicità che potrebbe portare all'identificazione di un individuo.

Chiavi di crittografia dei token

Per le trasformazioni di anonimizzazione crittografica, è richiesta una chiave di crittografia, nota anche come chiave di crittografia token. La chiave di crittografia del token utilizzata per la crittografia per l'anonimizzazione viene utilizzata anche per identificare nuovamente il valore originale. La creazione e la gestione sicure delle chiavi di crittografia dei token vanno oltre l'ambito di questo documento. Tuttavia, ci sono alcuni principi importanti da considerare utilizzati più avanti 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 in modo da ridurre il rischio di compromissione delle chiavi.
  • Ruota le chiavi di crittografia dei token. Anche se puoi ruotare la chiave con wrapping, la rotazione della chiave di crittografia del token interrompe l'integrità della tokenizzazione. Quando la chiave viene ruotata, è necessario ri tokenizzare l'intero set di dati.

Modelli di Sensitive Data Protection

Per deployment su larga scala, utilizza i modelli di protezione dei dati sensibili per eseguire quanto segue:

  • Abilitare il controllo della sicurezza con Identity and Access Management (IAM).
  • Disaccoppia le informazioni di configurazione e come anonimizzi tali informazioni dall'implementazione delle tue richieste.
  • Riutilizzare un insieme di trasformazioni. Puoi usare i modelli di anonimizzazione e reidentificazione su più set di dati.

BigQuery

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

Passaggi successivi