La assegnazione di pseudonimi è una tecnica di anonimizzazione che sostituisce i valori dei dati sensibili con token generati tramite crittografia. La pseudonimizzazione è ampiamente utilizzata in settori come la finanza e la sanità 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 anonimizzazione di pseudonimi e genera token applicando uno dei tre metodi di trasformazione crittografica ai valori originali dei dati sensibili. Ogni valore sensibile originale viene quindi sostituito con il token corrispondente. La pseudonimizzazione è talvolta nota come tokenizzazione o sostituzione surrogata.
Le tecniche di assegnazione di pseudonimi consentono l'attivazione di token unidirezionali o due vie. 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. Nei casi in cui non hai bisogno di reversibilità, puoi utilizzare token unidirezionali che impiegano meccanismi di hashing sicuri.
È utile capire in che modo l'assegnazione di pseudonimi può aiutare a proteggere i dati sensibili, consentendo al contempo alle operazioni aziendali e ai flussi di lavoro di analisi di accedere e utilizzare facilmente 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 assegnazione di pseudonimi 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 assegnazione di pseudonimi, tutte usando chiavi di crittografia. Di seguito sono riportati i metodi disponibili:
- Crittografia deterministica con AES-SIV: un valore di input viene sostituito con un valore criptato tramite l'algoritmo di crittografia AES-SIV con una chiave di crittografia, codificata con base64 e anteposto a un'annotazione surrogata, se specificata. Questo metodo produce un valore con hash, quindi non conserva il set di caratteri o la lunghezza del valore di input. I valori criptati e sottoposti ad hashing possono essere identificati nuovamente 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 tramite l'algoritmo di crittografia FPE-FFX con una chiave di crittografia e anteposto a un'annotazione surrogata, se specificata. In base alla progettazione, sia il set di caratteri sia la lunghezza del valore di input vengono conservati nel valore di output. I valori criptati possono essere identificati nuovamente utilizzando la chiave di crittografia originale e l'intero valore di output, inclusa l'annotazione surrogata. Per alcune importanti considerazioni sull'utilizzo di questo metodo di crittografia, consulta Crittografia con protezione del formato più avanti in questo argomento.
- Hashing crittografico: un valore di input viene sostituito con un valore criptato e sottoposto ad hashing mediante Hash-based Message Authentication Code (HMAC)-Secure Hash Algorithm (SHA)-256 nel valore di input con una chiave di crittografia. L'output con hash della trasformazione ha sempre la stessa lunghezza e non può essere identificato nuovamente. Scopri di più sul formato dei valori tokenizzati utilizzando l'hashing crittografico.
Questi metodi di assegnazione di pseudonimi sono riassunti nella seguente tabella. Le righe della tabella vengono spiegate dopo la tabella.
| Crittografia deterministica con AES-SIV | Crittografia con protezione del formato | Hashing crittografico | |
|---|---|---|---|
| Tipo di crittografia | AES-SIV | FPE-FFX | HMAC-SHA-256 |
| Valori di input supportati | Lunghezza di almeno 1 carattere; nessun limite al set di caratteri. | Lunghezza di almeno 2 caratteri; deve essere codificata come ASCII. | Deve essere una stringa o un valore intero. |
| Annotazione surrogata | Facoltativo. | Facoltativo. | N/A |
| Modifica del contesto | Facoltativo. | Facoltativo. | N/A |
| Set di caratteri e lunghezza conservati | ✗ | ✓ | ✗ |
| Reversibile | ✓ | ✓ | ✗ |
| Integrità dei riferimenti | ✓ | ✓ | ✓ |
- Tipo di crittografia: il tipo di crittografia utilizzato nella trasformazione di anonimizzazione.
- Valori di input supportati: requisiti minimi per i valori di input.
- Annotazione surrogata: un'annotazione specificata dall'utente anteposta ai valori criptati per fornire contesto agli utenti e fornire informazioni che la protezione dei dati sensibili può utilizzare per la reidentificazione di un valore anonimizzato. Per la reidentificazione dei dati non strutturati è necessaria un'annotazione surrogata. È facoltativo quando si trasforma 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 diversi valori di output. La modifica del contesto è facoltativa quando si trasforma una colonna di
dati strutturati, o tabulari, con un
RecordTransformation. Per scoprire di più, consulta la sezione Utilizzo delle modifiche al contesto. - 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 identificato nuovamente utilizzando la chiave di crittografia, l'annotazione surrogata e qualsiasi modifica di contesto.
- Integrità dei riferimenti:l'integrità referenziale consente ai record di mantenere la propria relazione tra loro anche dopo che i dati sono stati anonimizzati individualmente. Data la stessa chiave di crittografia e la stessa modifica di contesto, una tabella di dati verrà sostituita con lo stesso modulo offuscato 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 della 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 creare corrispondenze con i valori dei dati sensibili desiderati. Se esegui l'analisi dei dati strutturati (come una tabella BigQuery), puoi anche eseguire la tokenizzazione su intere colonne di dati utilizzando le trasformazioni dei record.
Per ulteriori informazioni sulle due categorie di trasformazioni (infoType e trasformazioni dei record), consulta Trasformazioni di anonimizzazione.
Passaggio 2: utilizzando una chiave di crittografia, Sensitive Data Protection cripta ogni valore di input. Puoi fornire questa chiave in tre modi:
- Eseguendo il wrapping tramite 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 elimina. Una chiave temporanea mantiene l'integrità solo per richiesta API. Se hai bisogno di integrità o hai intenzione di reidentificare questi dati, non utilizzare questo tipo di chiave.
- Direttamente in formato di testo non elaborato. (opzione non consigliata).
Per maggiori dettagli, consulta la sezione Utilizzo delle chiavi di crittografia più avanti in questo argomento.
Passaggio 3 (hashing crittografico e crittografia deterministica solo con AES-SIV): Sensitive Data Protection codifica il valore criptato utilizzando il formato base64. Con l'hashing crittografico, questo valore criptato e codificato è il token e il processo continua con il passaggio 6. Con la crittografia deterministica che utilizza AES-SIV, questo valore criptato e codificato è il valore surrogato, che è solo un componente del token. La procedura continua con il passaggio 4.
Passaggio 4 (conservazione del formato e crittografia deterministica solo con AES-SIV):
Sensitive Data Protection aggiunge un'annotazione surrogata facoltativa al valore criptato. L'annotazione surrogata consente di identificare i valori surrogati criptati anteponendo loro una stringa descrittiva da te definita. Ad esempio, senza un'annotazione potresti non riuscire a distinguere un numero di telefono anonimizzato e un numero di previdenza sociale o un altro numero di identificazione anonimizzati. Inoltre, per identificare nuovamente i valori nei dati non strutturati che sono stati anonimizzati utilizzando la crittografia con protezione del formato o la crittografia deterministica, devi specificare un'annotazione surrogata. Le annotazioni surrogate non sono necessarie quando
trasforma una colonna di dati strutturati o tabulari con un
RecordTransformation.
Passaggio 5 (conservazione del formato e crittografia deterministica solo con AES-SIV dei dati strutturati): Sensitive Data Protection può utilizzare il contesto facoltativo di un altro campo per "modificare" il token generato. Ciò consente di modificare l'ambito del token. Ad esempio, supponi di avere un database di dati delle campagne di marketing che include indirizzi email e di voler generare token univoci per lo stesso indirizzo email "modificato" dall'ID campagna. In questo modo, l'utente può unire i dati per lo stesso utente all'interno della stessa campagna, ma non in campagne diverse. Se viene utilizzata una modifica di contesto per creare il token, è necessaria anche questa modifica di contesto affinché le trasformazioni di anonimizzazione vengano invertite. Crittografia con protezione del formato e crittografia deterministica utilizzando i contesti di supporto AES-SIV. Scopri di più sull'utilizzo delle modifiche al contesto.
Passaggio 6: Sensitive Data Protection sostituisce il valore originale con il valore anonimizzato.
Confronto valori tokenizzati
Questa sezione mostra l'aspetto dei token tipici dopo essere stati anonimizzati utilizzando ciascuno dei tre metodi discussi in questo argomento. L'esempio di valore dei dati sensibili è un numero di telefono nordamericano (1-206-555-0123).
Crittografia deterministica mediante AES-SIV
Con l'anonimizzazione mediante crittografia deterministica e AES-SIV, un valore di input (e, facoltativamente, qualsiasi modifica al contesto specificata) viene criptato tramite AES-SIV con una chiave di crittografia, codificato utilizzando base64 e poi facoltativamente anteposto a un'annotazione surrogata, se specificata. Questo metodo non conserva il set di caratteri (o "alphabet") del valore di input. Per generare un output stampabile, il valore risultante è codificato in formato base64.
Il token risultante, supponendo che sia stato specificato un infoType surrogato, è nel formato:
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:
- Annotazione surogata
- InfoType surrogato (definito dall'utente)
- Lunghezza del valore trasformato in caratteri
- Valore surrogato (trasformato)
Se non specifichi un'annotazione surrogata, il token risultante è uguale al valore trasformato o n. 4 nel diagramma annotato. Per identificare nuovamente i dati non strutturati, è richiesto l'intero token, inclusa l'annotazione del surrogato. Quando trasformi i dati strutturati come una tabella, l'annotazione surrogata è facoltativa. Sensitive Data Protection può eseguire sia l'anonimizzazione e la reidentificazione su un'intera colonna utilizzando RecordTransformation senza un'annotazione surrogata.
Crittografia con protezione del formato
Con l'anonimizzazione mediante la crittografia con protezione del formato, un valore di input (e, facoltativamente, qualsiasi modifica al contesto specificata) viene criptato tramite la modalità FFX di crittografia con protezione del formato ("FPE-FFX") con una chiave di crittografia e, se specificata, viene facoltativamente anteposta a un'annotazione surrogata.
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 è codificato in base64. Sei tu a definire il set di caratteri, o "alphabet", che è composto dal valore criptato. Esistono tre modi per specificare l'alfabeto da utilizzare per la protezione dei dati sensibili nel valore di output:
- Utilizza uno dei quattro valori enumerati che rappresentano i quattro set di caratteri/alfabeti più comuni.
- Utilizza un valore radix che specifica le dimensioni dell'alfabeto. Se specifichi il
valore minimo della radice di
2, verrà restituito un alfabeto composto solo da0e1. Se viene specificato il valore radix massimo di95, verrà restituito un alfabeto che include tutti i caratteri numerici, alfanumerici maiuscoli, alfabetici minuscoli e simboli. - Crea un alfabeto elencando i caratteri esatti da usare. Ad esempio,
specificando
1234567890-*, otterrai un valore surrogato composto solo da numeri, trattini e asterischi.
La seguente tabella elenca quattro set di caratteri comuni in base al valore enumerato di ciascuno (FfxCommonNativeAlphabet), al valore del raggio e all'elenco dei caratteri del set. L'ultima riga elenca il set di caratteri completo, che corrisponde al valore radix massimo.
| Nome alfabeto/set di caratteri | Base | Elenco dei caratteri |
|---|---|---|
NUMERIC |
10 |
0123456789 |
HEXADECIMAL |
16 |
0123456789ABCDEF |
UPPER_CASE_ALPHA_NUMERIC |
36 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ |
ALPHA_NUMERIC |
62 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz |
| - | 95 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~`!@#$%^&*()_-+={[}]|\:;"'<,>.?/ |
Il token risultante, supponendo che sia stato specificato un infoType surrogato, è nel formato:
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 per il valore 1-206-555-0123 utilizzando una radice di 95. L'infoType surrogato facoltativo è
stato impostato su NAM_PHONE_NUMB:
- Annotazione surogata
- InfoType surrogato (definito dall'utente)
- Lunghezza del valore trasformato in caratteri
- Valore surrogato (trasformato): stessa lunghezza del valore di input
Se non specifichi un'annotazione surrogata, il token risultante è uguale al valore trasformato o n. 4 nel diagramma annotato. Per identificare nuovamente i dati non strutturati, è richiesto l'intero token, inclusa l'annotazione del surrogato. Quando trasformi i dati strutturati come una tabella, l'annotazione
surrogata è facoltativa; Sensitive Data Protection può eseguire sia
l'anonimizzazione e la reidentificazione su un'intera colonna utilizzando
RecordTransformation
senza un surrogato.
Hashing crittografico
Con l'anonimizzazione mediante hashing crittografico, un valore di input viene sottoposto ad hashing mediante HMAC-SHA-256 con una chiave di crittografia e quindi codificato in base64. Il valore anonimizzato ha sempre una lunghezza uniforme, a seconda delle dimensioni della chiave.
A differenza degli altri metodi di tokenizzazione illustrati in questo argomento, l'hashing crittografico crea un token unidirezionale. Ciò significa che l'anonimizzazione mediante hashing crittografico non può essere annullata.
Di seguito è riportato l'output di un'operazione di anonimizzazione mediante hashing crittografico sul valore 1-206-555-0123. Questo output è una rappresentazione con codifica Base64 del valore hash:
XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=
Utilizzo delle chiavi di crittografia
Esistono tre opzioni per le chiavi di crittografia che puoi utilizzare con i metodi di anonimizzazione crittografica di Sensitive Data Protection:
Chiave di crittografia con wrapping Cloud KMS: è il tipo di chiave di crittografia più sicuro disponibile per l'utilizzo con i metodi di anonimizzazione di Sensitive Data Protection. Una chiave con wrapping di Cloud KMS è composta da una chiave di crittografia a 128, 192 o 256 bit che è stata criptata utilizzando un'altra chiave. Devi fornire la prima chiave di crittografia, che viene quindi sottoposta a wrapping utilizzando una chiave di crittografia archiviata in Cloud Key Management Service. Questi tipi di chiavi sono archiviati in Cloud KMS per la reidentificazione in un secondo momento. Per ulteriori informazioni sulla creazione e sul wrapping di una chiave ai fini dell'anonimizzazione e della reidentificazione, consulta la pagina Guida rapida: anonimizzazione e reidentificazione di testo sensibile.
Chiave di crittografia temporanea: una chiave di crittografia temporanea viene generata da Sensitive Data Protection al momento dell'anonimizzazione e poi scartata. Per questo motivo, non utilizzare una chiave di crittografia temporanea con qualsiasi metodo di anonimizzazione crittografico che vuoi annullare. Le chiavi di crittografia temporanee mantengono solo l'integrità in base alla richiesta API. Se hai bisogno di integrità in più di una richiesta API o hai intenzione di reidentificare i tuoi dati, non utilizzare questo tipo di chiave.
Chiave di crittografia senza wrapping: una chiave senza wrapping è una chiave di crittografia non elaborata a 128, 192 o 256 bit con codifica Base64 che fornisci all'interno della richiesta di anonimizzazione all'API DLP. È tua responsabilità mantenere questo tipo di chiavi di crittografia protette per la reidentificazione in un secondo momento. A causa del rischio di perdita 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 è invece consigliata una chiave di crittografia con wrapping di Cloud KMS.
Per scoprire di più sulle opzioni disponibili quando utilizzi le chiavi di crittografia, consulta CryptoKey nel riferimento dell'API DLP.
Utilizzare le modifiche al contesto
Per impostazione predefinita, tutti i metodi di trasformazione crittografica di anonimizzazione hanno integrità referenziale, indipendentemente dal fatto che i token di output siano unidirezionali o bidirezionali. Ciò significa che, data la stessa chiave di crittografia, un valore di input viene sempre trasformato nello stesso valore criptato. Nelle situazioni in cui potrebbero verificarsi dati o pattern di dati ripetitivi, 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 un cambiamento di contesto univoco.
Puoi specificare un ritocco di contesto (denominato semplicemente context nell'API DLP) durante la trasformazione dei dati tabulari, dato che è effettivamente un puntatore a una colonna di dati, ad esempio un identificatore.
Sensitive Data Protection utilizza il valore nel campo specificato dalla modifica di contesto durante la crittografia del valore di input. Per assicurarti che il valore criptato sia sempre un valore univoco, specifica una colonna per la modifica che contiene identificatori univoci.
Considera questo semplice esempio. La tabella seguente mostra diverse cartelle cliniche, alcune delle quali includono ID paziente duplicati.
| record_id | patient_id | icd10_code |
|---|---|---|
| 5437 | 43789 | E11.9 |
| 5438 | 43671 | M25.531 |
| 5439 | 43789 | N39.0, I25.710 |
| 5440 | 43766 | I10 |
| 5441 | 43766 | I10 |
| 5442 | 42989 | R07.81 |
| 5443 | 43098 | I50.1 e R55 |
| ... | ... | ... |
Se indichi a Sensitive Data Protection di anonimizzare gli ID paziente nella tabella, per impostazione predefinita gli ID paziente ripetuti verranno anonimizzati con gli stessi valori, come mostrato nella tabella seguente. Ad esempio, entrambe le istanze dell'ID paziente "43789" sono anonimizzate come "47222". La colonna patient_id mostra i valori del token dopo l'assegnazione di pseudonimi mediante FPE-FFX e non include annotazioni surrogate. Per ulteriori informazioni, consulta Crittografia con protezione del formato.
| record_id | patient_id | icd10_codes |
|---|---|---|
| 5437 | 47222 | E11.9 |
| 5438 | 82160 | M25.531 |
| 5439 | 47222 | N39.0, I25.710 |
| 5440 | 04452 | I10 |
| 5441 | 04452 | I10 |
| 5442 | 47826 | R07.81 |
| 5443 | 52428 | I50.1 e R55 |
| ... | ... | ... |
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 un ritocco al contesto. Puoi specificare qualsiasi colonna come modifica del contesto, ma per garantire che ogni valore anonimizzato sia univoco, specifica una colonna per la quale ogni valore è univoco.
Supponi di voler vedere se lo stesso paziente viene visualizzato per ogni valore icd10_codes, ma non se lo stesso paziente viene visualizzato in valori icd10_codes diversi. Per farlo, devi specificare la colonna icd10_codes come ritocco di contesto.
Questa è la tabella dopo aver anonimizzato la colonna patient_id utilizzando la colonna icd10_codes come modifica al contesto:
| record_id | patient_id | icd10_codes |
|---|---|---|
| 5437 | 18954 | E11.9 |
| 5438 | 33068 | M25.531 |
| 5439 | 76368 | N39.0, I25.710 |
| 5440 | 29460 | I10 |
| 5441 | 29460 | I10 |
| 5442 | 23877 | R07.81 |
| 5443 | 96129 | I50.1 e R55 |
| ... | ... | ... |
Tieni presente che il quarto e il quinto valore patient_id anonimizzato (29460) sono gli stessi perché non solo i valori patient_id originali erano identici, ma anche i valori icd10_codes di entrambe le righe erano identici. Poiché hai dovuto eseguire l'analisi con ID paziente coerenti nell'ambito del valore icd10_codes, questo comportamento è ciò che stai cercando.
Per interrompere completamente l'integrità referenziale tra i valori patient_id e i valori icd10_codes, puoi utilizzare la colonna record_id come modifica del contesto:
| record_id | patient_id | icd10_code |
|---|---|---|
| 5437 | 15826 | E11.9 |
| 5438 | 61722 | M25.531 |
| 5439 | 34424 | N39.0, I25.710 |
| 5440 | 02875 | I10 |
| 5441 | 52549 | I10 |
| 5442 | 17945 | R07.81 |
| 5443 | 19030 | I50.1 e R55 |
| ... | ... | ... |
Tieni presente che ogni valore patient_id anonimizzato nella tabella ora è univoco.
Per scoprire come utilizzare le modifiche al contesto nell'API DLP, prendi nota dell'utilizzo di context nei seguenti argomenti di riferimento sui metodi di trasformazione:
- Crittografia con protezione del formato:
CryptoReplaceFfxFpeConfig - Crittografia deterministica mediante AES-SIV:
CryptoDeterministicConfig - Cambio data:
DateShiftConfig
Passaggi successivi
Esamina gli esempi di codice che dimostrano come tokenizzare i dati sensibili.
Scopri come anonimizzare i dati utilizzando l'API DLP.