Assegnazione di pseudonimi

L'assegnazione di pseudonimi è una tecnica di anonimizzazione che sostituisce i valori dei dati sensibili con token generati in modo crittografico. La pseudonimizzazione è ampiamente utilizzata in settori come quello finanziario e sanitario per contribuire a ridurre il rischio di dati in uso, restringere l'ambito di conformità e ridurre al minimo l'esposizione di dati sensibili ai sistemi, preservando al contempo l'utilità e l'accuratezza dei dati.

Sensitive Data Protection supporta tre tecniche di pseudonimizzazione di anonimizzazione e genera token applicando uno dei tre metodi di trasformazione crittografica ai valori dei dati sensibili originali. Ogni valore sensibile originale viene quindi sostituito con il token corrispondente. La pseudonimizzazione a volte viene chiamata tokenizzazione o sostituzione surrogata.

Le tecniche di pseudonimizzazione consentono di utilizzare token unidirezionali o bidirezionali. Un token unidirezionale è stato trasformato in modo irreversibile, mentre un token bidirezionale può essere invertito. Poiché il token viene creato utilizzando la crittografia simmetrica, la stessa chiave crittografica che può generare nuovi token può anche invertire i token. Per situazioni in cui non è necessaria la reversibilità, puoi utilizzare token unidirezionali che utilizzano meccanismi di hashing sicuri.

È utile capire come la pseudonimizzazione può contribuire a proteggere i dati sensibili consentendo alle operazioni aziendali e ai flussi di lavoro analitici di accedere facilmente e utilizzare i dati di cui hanno bisogno. Questo argomento esplora il concetto di pseudonimizzazione e i tre metodi crittografici per trasformare i dati supportati da Sensitive Data Protection.

Per istruzioni su come implementare questi metodi di pseudonimizzazione e per altri esempi di utilizzo di Sensitive Data Protection, consulta Anonimizzazione dei dati sensibili.

Metodi crittografici supportati in Sensitive Data Protection

Sensitive Data Protection supporta tre tecniche di pseudonimizzazione, tutte utilizzano chiavi crittografiche. Di seguito sono riportati i metodi disponibili:

• Crittografia deterministica con AES-SIV:un valore di input viene sostituito con un valore criptato utilizzando l'algoritmo di crittografia AES-SIV con una chiave crittografica, codificata utilizzando base64 e poi anteposta con un'annotazione surrogata, se specificata. Questo metodo produce un valore hash, pertanto non conserva il set di caratteri o la lunghezza del valore di input. I valori criptati con hash possono essere reidentificati utilizzando la chiave crittografica originale e l'intero valore di output, inclusa l'annotazione surrogata. Scopri di più sul formato dei valori tokenizzati utilizzando la crittografia AES-SIV.
• Crittografia con protezione del formato:un valore di input viene sostituito con un valore criptato utilizzando l'algoritmo di crittografia FPE-FFX con una chiave crittografica, quindi viene aggiunto un commento surrogato, se specificato. Per progettazione, sia il set di caratteri che la lunghezza del valore di input vengono conservati nel valore di output. I valori criptati possono essere reidentificati utilizzando la chiave di crittografia originale e l'intero valore di output, inclusa l'annotazione surrogata. Per alcune considerazioni importanti sull'utilizzo di questo metodo di crittografia, consulta la sezione Crittografia che preserva il formato più avanti in questa pagina.
• Hashing crittografico:un valore di input viene sostituito con un valore criptato e sottoposto ad hashing utilizzando Hash-based Message Authentication Code (HMAC)-Secure Hash Algorithm (SHA)-256 sul valore di input con una chiave crittografica. L'output sottoposto ad hashing della trasformazione ha sempre la stessa lunghezza e non può essere reidentificato. Scopri di più sul formato dei valori tokenizzati utilizzando l'hashing crittografico.

Questi metodi di pseudonimizzazione sono riassunti nella tabella seguente. Le righe della tabella sono spiegate dopo la tabella.

• Tipo di crittografia: il tipo di crittografia utilizzato nella trasformazione di deidentificazione.
• Valori di input supportati:requisiti minimi per i valori di input.
• Annotazione surrogata: un'annotazione specificata dall'utente che viene anteposta ai valori criptati per fornire contesto agli utenti e informazioni a Sensitive Data Protection da utilizzare per la reidentificazione di un valore anonimizzato. È necessaria un'annotazione surrogata per la reidentificazione dei dati non strutturati. È facoltativo quando trasformi una colonna di dati strutturati o tabulari con un RecordTransformation.
• Modifica del contesto:un riferimento a un campo di dati che "modifica" il valore di input in modo che valori di input identici possano essere anonimizzati in valori di output diversi. La modifica del contesto è facoltativa quando trasformi una colonna di dati strutturati o tabulari con un RecordTransformation. Per saperne di più, consulta Utilizzo delle modifiche contestuali.
• Set di caratteri e lunghezza preservati: indica se un valore anonimizzato è composto dallo stesso insieme di caratteri del valore originale e se la lunghezza del valore anonimizzato corrisponde a quella del valore originale.
• Reversibile: può essere reidentificato utilizzando la chiave di crittografia, l'annotazione surrogata e qualsiasi modifica del contesto.
• Integrità referenziale:l'integrità referenziale consente ai record di mantenere la loro relazione reciproca anche dopo che i loro dati sono stati anonimizzati individualmente. Data la stessa chiave crittografica e lo stesso aggiustamento del contesto, una tabella di dati verrà sostituita con la stessa forma offuscata ogni volta che viene trasformata, il che garantisce che le connessioni tra i valori (e, con i dati strutturati, i record) vengano mantenute, anche tra le tabelle.

Come funziona la tokenizzazione in Sensitive Data Protection

Il processo di base di tokenizzazione è lo stesso per tutti e tre i metodi supportati da Sensitive Data Protection.

Passaggio 1: Sensitive Data Protection seleziona i dati da tokenizzare. Il modo più comune per farlo è utilizzare un rilevatore di infoType integrato o personalizzato per trovare corrispondenze con i valori dei dati sensibili desiderati. Se esegui la scansione di dati strutturati (ad esempio una tabella BigQuery), puoi anche eseguire la tokenizzazione di intere colonne di dati utilizzando le trasformazioni dei record.

Per ulteriori informazioni sulle due categorie di trasformazioni, ovvero infoType e trasformazioni dei record, consulta Trasformazioni di anonimizzazione.

Passaggio 2: utilizzando una chiave crittografica, Sensitive Data Protection cripta ogni valore di input. Puoi fornire questa chiave in tre modi:

• Eseguendo il wrapping utilizzando Cloud Key Management Service (Cloud KMS). Per la massima sicurezza, Cloud KMS è il metodo preferito.
• Utilizzando una chiave temporanea, che Sensitive Data Protection genera al momento dell'anonimizzazione e poi scarta. Una chiave temporanea mantiene l'integrità per ogni richiesta API. Se hai bisogno di integrità o prevedi di reidentificare questi dati, non utilizzare questo tipo di chiave.
• Direttamente in formato testo non elaborato. (Non consigliato.)

Per maggiori dettagli, consulta la sezione Utilizzo delle chiavi crittografiche più avanti in questo argomento.

Passaggio 3 (hashing crittografico e crittografia deterministica solo con AES-SIV): Sensitive Data Protection codifica il valore criptato utilizzando Base64. Con l'hashing crittografico, questo valore codificato e criptato è il token e la procedura continua con il passaggio 6. Con la crittografia deterministica che utilizza AES-SIV, questo valore codificato e criptato è il valore surrogato, che è solo un componente del token. Il processo continua con il passaggio 4.

Passaggio 4 (crittografia deterministica e che preserva il formato solo con AES-SIV): Sensitive Data Protection aggiunge un'annotazione surrogata facoltativa al valore criptato. L'annotazione surrogata aiuta a identificare i valori surrogati criptati anteponendo loro una stringa descrittiva definita da te. Ad esempio, senza un'annotazione potresti non essere in grado di distinguere un numero di telefono anonimizzato da un codice fiscale o da un altro numero di identificazione anonimizzato. Inoltre, per reidentificare i valori nei dati non strutturati che sono stati deidentificati utilizzando la crittografia con protezione del formato o la crittografia deterministica, devi specificare un'annotazione surrogata. (Le annotazioni surrogate non sono necessarie quando si trasforma una colonna di dati strutturati o tabulari con un RecordTransformation.)

Passaggio 5 (crittografia deterministica e che preserva il formato con AES-SIV di soli dati strutturati): Sensitive Data Protection può utilizzare il contesto facoltativo di un altro campo per "modificare" il token generato. In questo modo puoi modificare l'ambito del token. Ad esempio, supponiamo che tu abbia un database di dati delle campagne di marketing che includono indirizzi email e che tu voglia generare token unici per lo stesso indirizzo email "modificato" dall'ID campagna. Ciò consentirebbe a qualcuno di unire i dati dello stesso utente all'interno della stessa campagna, ma non in campagne diverse. Se per creare il token viene utilizzato un aggiustamento del contesto, questo è necessario anche per invertire le trasformazioni di deidentificazione. Crittografia deterministica e con protezione del formato utilizzando i contesti di supporto AES-SIV. Scopri di più sull'utilizzo delle modifiche contestuali.

Passaggio 6: Sensitive Data Protection sostituisce il valore originale con il valore anonimizzato.

Confronto dei valori tokenizzati

Questa sezione mostra l'aspetto dei token tipici dopo la deidentificazione utilizzando ciascuno dei tre metodi descritti in questo argomento. Il valore di dati sensibili di esempio è un numero di telefono nordamericano (1-206-555-0123).

Crittografia deterministica che utilizza AES-SIV

Con la deidentificazione mediante crittografia deterministica e AES-SIV, un valore di input (e, facoltativamente, qualsiasi aggiustamento del contesto specificato) viene criptato utilizzando AES-SIV con una chiave crittografica, codificato utilizzando Base64 e poi, facoltativamente, anteposto con un'annotazione surrogata, se specificata. Questo metodo non conserva il set di caratteri (o "alfabeto") del valore di input. Per generare un output stampabile, il valore risultante viene codificato in base64.

Il token risultante, supponendo che sia stato specificato un infoType surrogato, ha la forma:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

Il seguente diagramma annotato mostra un token di esempio, l'output di un'operazione di anonimizzazione che utilizza la crittografia deterministica con AES-SIV sul valore 1-206-555-0123. L'infoType surrogato facoltativo è stato impostato su NAM_PHONE_NUMB:

1. Annotazione surrogata
2. Surrogato infoType (definito dall'utente)
3. Lunghezza in caratteri del valore trasformato
4. Valore surrogato (trasformato)

Se non specifichi un'annotazione surrogata, il token risultante è uguale al valore trasformato o a #4 nel diagramma annotato. Per reidentificare i dati non strutturati, è necessario l'intero token, inclusa l'annotazione surrogata. Quando trasformi dati strutturati come una tabella, l'annotazione surrogata è facoltativa; Sensitive Data Protection può eseguire sia la deidentificazione che la reidentificazione di un'intera colonna utilizzando un RecordTransformation senza un'annotazione surrogata.

Crittografia con protezione del formato

Con l'anonimizzazione tramite la crittografia con protezione del formato, un valore di input (e, facoltativamente, qualsiasi aggiustamento del contesto specificato) viene criptato utilizzando la modalità FFX della crittografia con protezione del formato ("FPE-FFX") con una chiave crittografica, quindi viene anteposto facoltativamente un'annotazione surrogata, se specificata.

A differenza degli altri metodi di tokenizzazione descritti in questo argomento, il valore surrogato di output ha la stessa lunghezza del valore di input e non viene codificato utilizzando base64. Definisci il set di caratteri, o "alfabeto", di cui è composto il valore criptato. Esistono tre modi per specificare l'alfabeto che Sensitive Data Protection deve utilizzare nel valore di output:

• Utilizza uno dei quattro valori enumerati che rappresentano i quattro set di caratteri/alfabeti più comuni.
• Utilizza un valore di base, che specifica la dimensione dell'alfabeto. Se specifichi il valore minimo della base di 2, l'alfabeto sarà composto solo da 0 e 1. Se specifichi il valore radix massimo di 95, l'alfabeto include tutti i caratteri numerici, le lettere maiuscole, le lettere minuscole e i simboli.
• Crea un alfabeto elencando i caratteri esatti da utilizzare. Ad esempio, se specifichi 1234567890-*, il valore surrogato sarà composto solo da numeri, trattini e asterischi.

La tabella seguente elenca quattro set di caratteri comuni in base al valore enumerato di ciascuno (FfxCommonNativeAlphabet), al valore della base e all'elenco dei caratteri del set. L'ultima riga elenca il set di caratteri completo, che corrisponde al valore radix massimo.

Il token risultante, supponendo che sia stato specificato un infoType surrogato, ha la forma:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

Il seguente diagramma annotato è l'output di un'operazione di anonimizzazione di Sensitive Data Protection che utilizza la crittografia con protezione del formato sul valore 1-206-555-0123 utilizzando una base di 95. L'infoType surrogato facoltativo è stato impostato su NAM_PHONE_NUMB:

1. Annotazione surrogata
2. Surrogato infoType (definito dall'utente)
3. Lunghezza in caratteri del valore trasformato
4. Valore surrogato (trasformato) con la stessa lunghezza del valore di input

Se non specifichi un'annotazione surrogata, il token risultante è uguale al valore trasformato o a #4 nel diagramma annotato. Per reidentificare i dati non strutturati, è necessario l'intero token, inclusa l'annotazione surrogata. Quando trasformi dati strutturati come una tabella, l'annotazione surrogata è facoltativa; Sensitive Data Protection può eseguire sia la deidentificazione che la reidentificazione di un'intera colonna utilizzando un RecordTransformation senza un surrogato.

Hashing crittografico

Con la deidentificazione tramite hashing crittografico, un valore di input viene sottoposto ad hashing utilizzando HMAC-SHA-256 con una chiave crittografica e poi codificato utilizzando Base64. Il valore anonimizzato ha sempre una lunghezza uniforme, a seconda delle dimensioni della chiave.

A differenza degli altri metodi di tokenizzazione descritti in questo argomento, l'hashing crittografico crea un token unidirezionale. ovvero l'anonimizzazione tramite hashing crittografico non può essere annullata.

Di seguito è riportato l'output di un'operazione di anonimizzazione che utilizza l'hashing crittografico sul valore 1-206-555-0123. Questo output è una rappresentazione con codifica Base64 del valore hash:

XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=

Utilizzo delle chiavi crittografiche

Esistono tre opzioni per le chiavi di crittografia che puoi utilizzare con i metodi di anonimizzazione crittografica in Sensitive Data Protection:

• Chiave di crittografia con wrapping Cloud KMS: questo è il tipo di chiave di crittografia più sicuro disponibile per l'utilizzo con i metodi di deidentificazione di Sensitive Data Protection. Una chiave con wrapping Cloud KMS è costituita da una chiave di crittografia a 128, 192 o 256 bit criptata utilizzando un'altra chiave. Fornisci la prima chiave crittografica, che viene poi sottoposta a wrapping utilizzando una chiave crittografica archiviata in Cloud Key Management Service. Questi tipi di chiavi vengono memorizzati in Cloud KMS per la reidentificazione successiva. Per ulteriori informazioni sulla creazione e sul wrapping di una chiave ai fini dell'anonimizzazione e della reidentificazione, consulta la guida rapida: anonimizzazione e reidentificazione del testo sensibile.

• Chiave di crittografia temporanea: una chiave di crittografia temporanea viene generata da Sensitive Data Protection al momento della deidentificazione e poi eliminata. Per questo motivo, non utilizzare una chiave di crittografia temporanea con qualsiasi metodo di deidentificazione crittografica che vuoi invertire. Le chiavi di crittografia temporanee mantengono l'integrità solo per richiesta API. Se hai bisogno di integrità in più di una richiesta API o prevedi di identificare nuovamente i tuoi dati, non utilizzare questo tipo di chiave.

• Chiave di crittografia senza wrapping: una chiave senza wrapping è una chiave di crittografia non elaborata con codifica base64 a 128, 192 o 256 bit che fornisci all'interno della richiesta di de-identificazione all'API DLP. È tua responsabilità conservare al sicuro questi tipi di chiavi crittografiche per la successiva reidentificazione. A causa del rischio di divulgazione accidentale della chiave, questi tipi di chiavi non sono consigliati. Queste chiavi possono essere utili per i test, ma per i carichi di lavoro di produzione è consigliata una chiave di crittografia aggregata Cloud KMS.

Per scoprire di più sulle opzioni disponibili quando utilizzi le chiavi di crittografia, consulta CryptoKey nel riferimento API DLP.

Utilizzo delle modifiche contestuali

Per impostazione predefinita, tutti i metodi di trasformazione crittografica di deidentificazione hanno integrità referenziale, indipendentemente dal fatto che i token di output siano unidirezionali o bidirezionali. ovvero, data la stessa chiave crittografica, un valore di input viene sempre trasformato nello stesso valore criptato. In situazioni in cui potrebbero verificarsi dati ripetitivi o pattern di dati, il rischio di reidentificazione aumenta. Per fare in modo che lo stesso valore di input venga sempre trasformato in un valore criptato diverso, puoi specificare una modifica del contesto univoca.

Quando trasformi dati tabulari, specifichi una modifica del contesto (denominata semplicemente context nell'API DLP), poiché la modifica è effettivamente un puntatore a una colonna di dati, ad esempio un identificatore. La protezione dei dati sensibili utilizza il valore nel campo specificato dalla modifica del contesto durante la crittografia del valore di input. Per assicurarti che il valore criptato sia sempre univoco, specifica una colonna per la modifica che contenga identificatori univoci.

Considera questo semplice esempio. La seguente tabella mostra diverse cartelle cliniche, alcune delle quali includono ID paziente duplicati.

Se chiedi a Sensitive Data Protection di anonimizzare gli ID paziente nella tabella, per impostazione predefinita anonimizza gli ID paziente ripetuti con gli stessi valori, come mostrato nella tabella seguente. Ad esempio, entrambe le istanze dell'ID paziente "43789" vengono rese anonime con "47222". La colonna patient_id mostra i valori dei token dopo la pseudonimizzazione utilizzando FPE-FFX e non include annotazioni surrogate. Per saperne di più, consulta Crittografia con protezione del formato.

Ciò significa che l'ambito dell'integrità referenziale riguarda l'intero set di dati.

Per restringere l'ambito in modo da evitare questo comportamento, specifica una modifica del contesto. Puoi specificare qualsiasi colonna come aggiustamento contestuale, ma per garantire che ogni valore anonimizzato sia univoco, specifica una colonna per cui ogni valore è univoco.

Supponiamo che tu voglia vedere se lo stesso paziente compare per valore icd10_codes ma non se lo stesso paziente compare in valori icd10_codes diversi. Per farlo, devi specificare la colonna icd10_codes come aggiustamento del contesto.

Questa è la tabella dopo l'anonimizzazione della colonna patient_id utilizzando la colonna icd10_codes come aggiustamento del contesto:

Tieni presente che il quarto e il quinto valore patient_id deidentificato (29460) sono uguali perché non solo i valori patient_id originali erano identici, ma anche i valori icd10_codes di entrambe le righe erano identici. Poiché dovevi eseguire l'analisi con ID paziente coerenti nell'ambito del valore icd10_codes, questo comportamento è quello che stai cercando.

Per interrompere completamente l'integrità referenziale tra i valori patient_id e icd10_codes, puoi utilizzare la colonna record_id come aggiustamento del contesto:

Tieni presente che ogni valore patient_id anonimizzato nella tabella ora è univoco.

Per scoprire come utilizzare le modifiche contestuali nell'API DLP, prendi nota dell'utilizzo di context nei seguenti argomenti di riferimento del metodo di trasformazione:

• Crittografia con protezione del formato: CryptoReplaceFfxFpeConfig
• Crittografia deterministica con AES-SIV: CryptoDeterministicConfig
• Spostamento della data: DateShiftConfig

Passaggi successivi

• Consulta un esempio end-to-end che mostra come creare una chiave protetta, tokenizzare i contenuti e reidentificare i contenuti tokenizzati.

• Esamina gli esempi di codice che mostrano come tokenizzare i dati sensibili.

• Scopri come anonimizzare i dati utilizzando l'API DLP.