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 assegnazione di pseudonimi 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 del surrogato.

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 di crittografia 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 la trasformazione dei dati supportati dalla protezione dei dati sensibili.

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 pseudonimizzazione, tutte utilizzano chiavi crittografiche. Di seguito sono riportati i metodi disponibili:

• Crittografia deterministica tramite AES-SIV: Un valore di input viene sostituito con un valore crittografato utilizzando l'algoritmo di crittografia AES-SIV con una chiave di crittografia, codificata in base64 e quindi preceduta da un'annotazione surrogata, se specificata. Questo metodo produce un valore hash, quindi non conserva il set di caratteri o la lunghezza del valore di input. I valori crittografati e sottoposti a hashing possono essere reidentificati utilizzando la chiave di crittografia originale e l'intero valore di output, comprese le annotazioni surrogate. 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 crittografato utilizzando l'algoritmo crittografico FPE-FFX con una chiave di crittografia, quindi viene aggiunto un commento surrogato, se specificato. Per progettazione, sia il set di caratteri sia 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, vedere Crittografia che preserva il formato più avanti in questo argomento.)
• Hashing crittografico:un valore di input viene sostituito con un valore crittografato e sottoposto ad hashing utilizzando Hash-based Message Authentication Code (HMAC)-Secure Hash Algorithm (SHA)-256 sul valore di input con una chiave di crittografia. 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 da utilizzare in Sensitive Data Protection 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 di contesto.
• Set di caratteri e lunghezza preservati: Indica se un valore de-identificato è composto dallo stesso set di caratteri del valore originale e se la lunghezza del valore de-identificato corrisponde a quella del suo 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 modifica del contesto, una tabella di dati verrà sostituita con la stessa forma offuscata ogni volta che viene trasformata, garantendo che le connessioni tra i valori (e, con i dati strutturati, i record) siano preservate, anche tra tabelle diverse.

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 saperne di più sulle due categorie di trasformazioni, infoType e record, consulta Trasformazioni di anonimizzazione.

Passaggio 2: utilizzando una chiave di crittografia, Sensitive Data Protection crittografa 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à solo per la singola richiesta API. Se hai bisogno di integrità o prevedi di reidentificare questi dati, non utilizzare questo tipo di chiave.
• Direttamente in formato testo grezzo. (Opzione non consigliata.)

Per maggiori dettagli, consultare 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 crittografato 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 tramite AES-SIV, questo valore codificato e criptato è il valore surrogato, che è solo un componente del token. Il processo prosegue con la Fase 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 anonimizzati utilizzando la crittografia che preserva il formato o la crittografia deterministica, è necessario specificare un'annotazione surrogata. (Le annotazioni surrogate non sono necessarie quando si trasforma una colonna di dati strutturati o tabellari con unRecordTransformation.)

Passaggio 5 (crittografia deterministica e con conservazione del formato con AES-SIV solo per dati strutturati): Sensitive Data Protection può utilizzare il contesto opzionale di un altro campo per "modificare" il token generato. In questo modo puoi modificare l'ambito del token. Ad esempio, supponiamo di avere un database di dati di campagne di marketing che include indirizzi email e di voler generare token univoci per lo stesso indirizzo email "modificato" dall'ID campagna. Ciò consentirebbe di unire i dati relativi allo stesso utente all'interno della stessa campagna, ma non tra campagne diverse. Se per creare il token viene utilizzata una modifica del contesto, tale modifica è necessaria anche per annullare le trasformazioni di de-identificazione. Crittografia deterministica e con protezione del formato utilizzando 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 tipico dei token dopo essere stati anonimizzati utilizzando ciascuno dei tre metodi discussi in questo argomento. Il valore di esempio dei dati sensibili è un numero di telefono nordamericano (1-206-555-0123).

Crittografia deterministica che utilizza AES-SIV

Con l'anonimizzazione mediante crittografia deterministica e AES-SIV, un valore di input (e, facoltativamente, qualsiasi aggiustamento del contesto specificato) viene crittografato utilizzando AES-SIV con una chiave di crittografia, codificato utilizzando Base64 e poi, facoltativamente, anteposto con un'annotazione surrogata, se specificata. Questo metodo non preserva 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 surrogato infoType, è nel formato:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

Il seguente diagramma annotato mostra un esempio di token: l'output di un'operazione di de-identificazione tramite crittografia deterministica con AES-SIV sul valore 1-206-555-0123. Il surrogato infoType facoltativo è stato impostato su NAM_PHONE_NUMB:

1. Annotazione surrogata
2. InfoType surrogato (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 sia la reidentificazione di un'intera colonna utilizzando un RecordTransformation senza un'annotazione surrogata.

Crittografia con protezione del formato

Con l'anonimizzazione tramite crittografia che preserva il formato, un valore di input (e, facoltativamente, qualsiasi modifica di contesto specificata) viene crittografato utilizzando la modalità FFX di crittografia che preserva il formato ("FPE-FFX") con una chiave di crittografia e quindi, facoltativamente, viene preceduta da 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 è codificato in 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. Specificando il valore minimo della base 2 si ottiene un alfabeto composto solo da 0 e 1. Se specifichi il valore radix massimo di 95, l'alfabeto include tutti i caratteri numerici, i caratteri alfabetici maiuscoli, i caratteri alfabetici minuscoli e i simboli.
• Crea un alfabeto elencando i caratteri esatti da utilizzare. Ad esempio, specificando 1234567890-* si otterrebbe un valore surrogato composto solo da numeri, trattini e asterischi.

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

Il token risultante, supponendo che sia stato specificato un surrogato infoType, ha il seguente formato:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

Il seguente diagramma annotato è l'output di un'operazione di de-identificazione di Sensitive Data Protection utilizzando la crittografia che preserva il formato sul valore 1-206-555-0123 utilizzando una base di 95. Il infoType surrogato facoltativo è stato impostato su NAM_PHONE_NUMB:

1. Annotazione surrogata
2. InfoType surrogato (definito dall'utente)
3. Lunghezza in caratteri del valore trasformato
4. Valore surrogato (trasformato): 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 l'anonimizzazione tramite hashing crittografico, un valore di input viene sottoposto ad hashing utilizzando HMAC-SHA-256 con una chiave di crittografia 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. Ciò significa che la de-identificazione tramite hashing crittografico non è reversibile.

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 anonimizzazione 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. Tu fornisci la prima chiave di crittografia, che viene poi crittografata utilizzando una chiave di crittografia archiviata nel servizio 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 a 128, 192 o 256 bit con codifica base64 che fornisci all'interno della richiesta di anonimizzazione all'API DLP. Sei responsabile di conservare al sicuro questi tipi di chiavi crittografiche per la successiva reidentificazione. A causa del rischio di perdite accidentali della chiave, questo tipo di chiavi non è raccomandato. Queste chiavi possono essere utili per i test, ma per i carichi di lavoro di produzione si consiglia invece una chiave di crittografia incapsulata in Cloud KMS.

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

Utilizzo delle modifiche contestuali

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 crittografato. 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.

Si specifica una modifica del contesto (denominata semplicemente unacontext nell'API DLP) durante la trasformazione di dati tabellari, poiché la modifica è di fatto un puntatore a una colonna di dati, come un identificatore. Sensitive Data Protection utilizza il valore nel campo specificato dalla modifica del contesto durante la crittografia del valore di input. Per garantire che il valore crittografato sia sempre univoco, specificare 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 si imposta Sensitive Data Protection in modo che anonimizzi gli ID dei pazienti nella tabella, gli ID dei pazienti duplicati vengono anonimizzati automaticamente 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 l'assegnazione di pseudonimi tramite FPE-FFX e non include annotazioni surrogate. Vedere Crittografia che preserva il formato per ulteriori informazioni.)

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

Per restringere l'ambito e quindi evitare questo comportamento, specifica una modifica del contesto. È possibile specificare qualsiasi colonna come modifica del contesto, ma per garantire che ogni valore anonimizzato sia univoco, è necessario specificare una colonna per la quale ogni valore sia univoco.

Supponiamo di voler verificare se lo stesso paziente compare per ogni 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:

Si noti che il quarto e il quinto valore patient_id de-identificato (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é avevi bisogno di eseguire l'analisi con ID paziente coerenti all'interno dell'intervallo del valore icd10_codes, questo comportamento è quello che stavi cercando.

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

Si noti che ogni valore patient_id anonimizzato nella tabella è ora univoco.

Per informazioni su come utilizzare le modifiche di contesto nell'API DLP, si noti l'utilizzo di context nei seguenti argomenti di riferimento sui metodi di trasformazione:

• Crittografia che preserva il formato:CryptoReplaceFfxFpeConfig
• Crittografia deterministica con AES-SIV: CryptoDeterministicConfig
• Date shifting: DateShiftConfig

Passaggi successivi

• Segui 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 de-identificare i dati utilizzando l'API DLP.