Analisi del rischio di reidentificazione

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

L'analisi del rischio di reidentificazione (o semplicemente l'analisi del rischio) è il processo di analisi di dati sensibili per trovare proprietà che potrebbero aumentare il rischio di identificazione dei soggetti o informazioni sensibili sugli individui mostrati. Puoi utilizzare i metodi di analisi dei rischi prima che l'anonimizzazione contribuisca a determinare una strategia di anonimizzazione efficace o dopo l'anonimizzazione per monitorare eventuali variazioni o anomalie.

L'anonimizzazione è il processo di rimozione delle informazioni identificative dai dati. Cloud Data Loss Prevention può rilevare e anonimizzare i dati sensibili, in base al modo in cui li hai configurati in modo che siano conformi ai requisiti della tua organizzazione.

Al contrario, la reidentificazione è la procedura di abbinamento dei dati anonimizzati con altri dati disponibili per determinare la persona a cui appartengono i dati. Nell'ambito delle informazioni personali sensibili, come i dati medici o finanziari, si parla più spesso di reidentificazione.

Per ulteriori informazioni sull'utilizzo di Cloud DLP per misurare vari tipi di rischi, consulta la pagina relativa alla misurazione del rischio di reidentificazione e divulgazione.

Termini e tecniche di analisi del rischio

Se non identifichi in modo corretto o adeguato i dati sensibili, rischi di identificare un individuo che attacca i dati, oppure di acquisire informazioni sensibili sui singoli individui, che possono avere gravi conseguenze sulla privacy. Cloud DLP può calcolare questo rischio in base a diverse metriche.

Prima di analizzare le metriche, definiscono innanzitutto alcuni termini comuni:

  • Identificatori: gli identificatori possono essere utilizzati per identificare in modo univoco una persona. Ad esempio, il nome completo o il numero di documento di identità di una persona sono considerati identificatori.
  • Quasi-identifier: gli identificatori quasi non identificano in modo univoco un individuo, ma quando combinati e incrociati con singoli record, possono aumentare notevolmente la probabilità che un utente malintenzionato possa identificare nuovamente un individuo. Ad esempio, i codici postali e le età sono considerati quasi-identificatori.
  • Dati sensibili: i dati sensibili sono protetti dalle esposizioni non autorizzate. Attributi come condizioni sanitarie, stipendio, reato e posizione geografica sono in genere considerati dati sensibili. Tieni presente che possono esserci sovrapposizioni tra identificatori e dati sensibili.
  • Classi di equivalenza: una classe di equivalenza è un gruppo di righe con quasi-identificatori identici.

Esistono quattro tecniche che Cloud DLP può utilizzare per quantificare il livello di rischio associato a un set di dati:

  • k-anonymity: una proprietà di un set di dati che indica la reidentificabilità dei suoi record. Un set di dati è k-anonymous se i quasi-identificatori per ogni persona nel set di dati sono identici ad almeno k - 1 altra persona anche nel set di dati.
  • l-diversity: un'estensione di k-anonymity che misura anche la diversità dei valori sensibili per ogni colonna in cui si presentano. Un set di dati ha l-diversity se, per ogni insieme di righe con quasi-identificatori identici, esistono almeno l valori distinti per ciascun attributo sensibile.
  • k-map: calcola il rischio di reidentificabilità confrontando un determinato set di dati anonimizzato dei soggetti con un set di dati di reidentificazione più ampio, o "quot&atta",. Cloud DLP non conosce il set di dati degli attacchi, ma lo modella in modo statistico utilizzando dati disponibili pubblicamente come il censimento degli Stati Uniti, utilizzando un modello statistico personalizzato (indicato come una o più tabelle BigQuery) oppure estrapolando dalla distribuzione dei valori nel set di dati di input. Ogni set di dati, cioè il set di dati di esempio e il set di dati di reidentificazione, condivide una o più colonne quasi identificative.
  • Delta-presence (')}>-presence: stima la probabilità che un dato utente in una popolazione più ampia sia presente nel set di dati. Viene utilizzato quando l'appartenenza al set di dati contiene informazioni sensibili. Analogamente a k-map, Cloud DLP non conosce il set di dati dell'attacco, ma lo modella statisticamente utilizzando dati disponibili pubblicamente, distribuzioni specificate dall'utente o estrapolazione dal set di dati di input.

Informazioni su k-anonymity

Quando raccogli i dati per finalità di ricerca, l'anonimizzazione può essere fondamentale per contribuire a mantenere la privacy dei partecipanti. Allo stesso tempo, l'anonimizzazione può far sì che un set di dati perda la sua utilità pratica. È stato ricavato l'anonimizzazione k a partire dalla necessità di quantificare la reidentificabilità di un set di dati e di bilanciare l'utilità dei dati anonimizzati delle persone e la privacy delle persone i cui dati vengono utilizzati. È una proprietà di un set di dati che può essere utilizzato per valutare la reidentificabilità dei record all'interno del set di dati.

Ad esempio, considera un insieme di dati di pazienti:

ID paziente Nome e cognome CAP Età Condizione
746572 Giovanni R. Jacobsen 98122 29 Malattia cardiaca
652978 Debra D Dreb 98115 29 Diabete, Tipo II
075321 Abramo A. Abernazia 98122 54 Cancro, fegato
339012 Karen K. Cracovia 98115 88 Malattia cardiaca
995212 William W. Wertheimer 98115 54 Asma

Questo set di dati contiene tutti e tre i tipi di dati descritti in precedenza: identificatori, quasi-identificatori e dati sensibili.

Se dati sensibili come le condizioni di salute non sono mascherati o oscurati, un utente malintenzionato potrebbe utilizzare i quasi-identificatori a cui è associato, potenzialmente facendo un riferimento incrociato con un altro set di dati che contiene identificatori simili e riidentificando le persone a cui si applicano tali dati.

Si dice che un set di dati sia k anonimo se ogni combinazione di valori per le colonne demografiche nel set di dati viene visualizzata per almeno k record diversi. Ricordiamo che un gruppo di righe con quasi-identificatori identici è chiamato classe di equivalenza." Ad esempio, se hai anonimizzato i quasi-identificatori, abbastanza che ci siano almeno quattro righe i cui valori quasi-identificatori sono identici, il valore k-anonymity del set di dati è 4.

ID entità e calcolo dell'anonimato di k

Un'opzione importante che Cloud DLP include per il calcolo di k-anonymity è l'identificatore di entità (ID) facoltativo. Un ID entità consente di determinare con maggiore precisione l'anonimato k nello scenario comune in cui diverse righe del set di dati corrispondono allo stesso utente. In caso contrario, se ogni riga, indipendentemente dall'utente, viene conteggiata separatamente, il numero totale di utenti utilizzato per calcolare il valore k-anonymity di il set di dati viene reso artificialmente elevato. I valori k-anonymity calcolati non sono precisi.

Prendi in considerazione il seguente insieme di dati semplice:

ID utente Codice postale
01 42000
02 17000
02 42000
03 17000
03 42000
03 42000
04 42000
04 17000

Senza utilizzare un ID entità per notare che righe diverse appartengono allo stesso utente, il numero totale di utenti utilizzato per il calcolo dell'anonimato k è 8, anche se il numero effettivo di utenti è 4. In questo set di dati, utilizzando i metodi di calcolo tradizionali k-anonymity (senza un ID entità), tre persone hanno un valore k-anonymity di 3 e 5 persone hanno un valore k-anonymity di 5, anche se il database contiene solo quattro persone effettive.

L'utilizzo di un ID entità fa sì che Cloud DLP prenda in considerazione il multiinsieme di codici postali a cui un utente è associato come quasi-identificatore durante il calcolo di k-anonymity. Nel caso del nostro esempio, ci sono in realtà tre valori quasi-identificatori perché sono presenti tre combinazioni distinte di quasi-identificatore assegnato agli utenti: 42000, il multiinsieme 17000 e 42000 e il multiinsieme 17000, 42000 e 42000, Corrispondono agli utenti nel seguente modo:

  • [42000] è associato a 1 utente unico (01).
  • [17000, 42000] è associato a 2 utenti unici (02 e 04).
  • [17000, 42000, 42000] è associato a un utente unico (03).

Come puoi vedere, questo metodo prende in considerazione il fatto che gli utenti potrebbero essere presenti più volte nel nostro database ZIP e li considera di conseguenza quando calcola l'anonimato di k.

Risorse k-anonymity

Per ulteriori informazioni sull'anonimizzazione k, consulta la sezione Proteggere la privacy quando si divulgano informazioni: k-Anonymity and It Enforcement through Generalization and Suppression, di Pierangela Samarati e Latanya Sweeney del Data Privacy University di Harvard.

Per informazioni su come calcolare l'anonimato k con Cloud DLP, con o senza ID entità, consulta l'articolo Computazione dell'anonimato k per un set di dati.

Informazioni su l-diversity

l-diversity è strettamente correlato a k-anonymity ed è stato creato per aiutare ad affrontare la suscettibilità di un set di dati anonimizzato ad attacchi come:

  • Attacchi di omogeneità, in cui gli utenti malintenzionati prevedono valori sensibili per un set di dati k anonimizzati sfruttando l'omogeneità dei valori all'interno di un set di record k.
  • Attacchi basati sulle conoscenze in background, in cui gli utenti malintenzionati sfruttano le associazioni di valori quasi-identificatori con un determinato attributo sensibile per limitare i valori dell'attributo.

l-diversity tenta di misurare quanto un utente malintenzionato può imparare a conoscere le persone in termini di k-anonimato e classi di equivalenza (insiemi di righe con valori identici di quantis). Un set di dati ha l-diversity se, per ogni classe di equivalenza, esistono almeno l valori univoci per ogni attributo sensibile. Per ogni classe di equivalenza, quanti attributi sensibili sono presenti nel set di dati? Ad esempio, se l-diversity = 1, tutti hanno lo stesso attributo sensibile, se l-diversity = 2, significa che tutti hanno uno dei due attributi sensibili e così via.

Risorse dell'area

Per ulteriori informazioni su l-diversity, consulta la sezione l-Diversity: Privacy Beyond k-Anonymity, di Ashwin Machanavajjhala, Johannes Gerke e Daniel Kifer del dipartimento di informatica della Cornell.

Per informazioni su come calcolare l-diversity con Cloud DLP, consulta Computing l-diversity per un set di dati.

Informazioni su k-map

k-map è molto simile a k-anonymity, tranne per il presupposto che l'attaccante molto probabilmente non sappia chi si trova nel set di dati. Utilizza k-map se il set di dati è relativamente piccolo o se il livello di impegno nella definizione degli attributi è troppo elevato.

Proprio come k-anonymity, k-map richiede che tu determini quali colonne del tuo database sono quasi-identificatori. In questo modo, indichi quali dati verranno utilizzati con maggiore probabilità da un utente malintenzionato per identificare nuovamente i soggetti. Inoltre, il calcolo di un valore k della mappa richiede un set di dati di reidentificazione: una tabella più grande con cui confrontare le righe nel set di dati originale.

Considera il seguente piccolo set di dati di esempio. Questi dati di esempio fanno parte di un database ipotetico più ampio, raccolto da un sondaggio le cui risposte includevano informazioni sensibili.

Codice postale età
85535 79
60629 42

Considerate singolarmente, questa quantità di informazioni sembra essere la stessa per entrambi. Infatti, se consideriamo k-anonymity per il set di dati più grande, potresti affermare che il soggetto corrispondente alla seconda riga è altamente identificabile. Tuttavia, se effettui il backup e valuti i dati, ti rendi conto che non è così. In particolare, prendi in considerazione il codice postale degli Stati Uniti 85535, in cui al momento vivono circa 20 persone. Probabilmente una sola persona di età pari a 79 anni vive nel codice postale 85535. Confrontalo con il codice postale 60629, che fa parte dell'area metropolitana di Chicago e ospita oltre 100.000 persone. Il codice postale corrisponde a circa 1000 persone di esattamente 42 anni di età.

La prima riga nel nostro piccolo set di dati è stata facilmente identificata, ma non la seconda. Secondo k-anonymity, tuttavia, entrambe le righe potrebbero essere completamente uniche nel set di dati più grande.

k-map, come k-anonymity, ti richiede di determinare quali colonne del tuo database sono quasi-identificatori. Le API di analisi del rischio di Cloud DLP simulano un set di dati di reidentificazione per approssimare i passaggi che un utente malintenzionato potrebbe seguire per confrontare il set di dati originale al fine di identificare nuovamente i dati. Per il nostro esempio precedente, in quanto riguarda le località degli Stati Uniti (codici postali) e i dati personali (età) e, presumendo che l'utente malintenzionato non sappia chi ha partecipato al sondaggio, il set di dati di reidentificazione potrebbe essere chiunque abbia sede negli Stati Uniti.

Ora che hai quasi-identificatori e un set di dati di reidentificazione, puoi calcolare il valore k -mappa: i tuoi dati soddisfano la mappa k con il valore k se ogni combinazione di valori per i quasi-identificatori appare almeno k volte nel set di dati di reidentificazione.

Data questa definizione, e che la prima riga del nostro database probabilmente corrisponde a una sola persona negli Stati Uniti, il set di dati di esempio non soddisfa un requisito di valore di mappa k pari o superiore a 2. Per ottenere un valore maggiore della mappa k, potremmo rimuovere valori di età come abbiamo fatto qui:

Codice postale età
85535 **
60629 **

Come accennato in precedenza, il codice postale 85535 ha circa 20 persone e 60629 ha più di 100.000. Pertanto, possiamo stimare che questo nuovo set di dati generali avrà un valore k pari a circa 20.

Risorse k-map

Per ulteriori informazioni su k-map e sul suo rapporto con k-anonymity, consulta la sezione Protecting Privacy using k-Anonymity, di Khaled El Emam e Fida Kamal Dankar, sul sito Journal of the American Medical Informatics Association.

Per informazioni su come calcolare le stime della mappa k con Cloud DLP, consulta Mappatura k di una mappa per un set di dati.

Informazioni sulla presenza

La presenza di delta (previsioni gclid) stima il rischio associato a un utente malintenzionato che vuole scoprire se il suo target è nel set di dati. Questo è leggermente diverso dal rischio di reidentificazione in quanto l'obiettivo non è trovare il record esatto che corrisponde a un individuo, ma solo sapere se una persona fa parte del set di dati. L'utilizzo di questa metrica è particolarmente appropriato se tutte le persone nel set di dati condividono un attributo sensibile comune, ad esempio, tutte hanno la stessa diagnosi medica.

Come nel caso delle altre metriche di rischio, la presenza SafeSearch richiede la determinazione delle colonne del database come quasi-identificatori. In questo modo, indichi i dati che un utente malintenzionato probabilmente utilizzerà per individuare gli utenti nel set di dati. Come per k-map, il calcolo della presenza di gclid richiede un set di dati di attacco: una tabella più grande con cui confrontare le righe nel set di dati originale.

Considera il seguente piccolo set di dati di esempio. Questi dati di esempio fanno parte di un più ampio database ipotetico di persone con una determinata malattia genetica.

Codice postale età
85942 72
85942 72
62083 53

Nel codice postale degli Stati Uniti 85942 ci sono circa 2 persone di età pari a 72 anni, mentre nel codice postale 62083 ci sono circa 5 persone di età pari a 53 anni. I primi due record non sono riidentificabili esattamente perché entrambi hanno gli stessi identificatori quasi. Tuttavia, poiché solo due individui condividono questi quasi-identificatori nella popolazione più ampia, un utente malintenzionato può dedurre che entrambi soffrono della malattia genetica. La presenza SafeSearch quantifica questo rischio specifico calcolando il rapporto tra le persone con determinati quasi-identificatori presenti nel set di dati.

La presenza di gclid, come le altre metriche di rischio, richiede che tu determini quali colonne del database sono quasi-identificatori. E come per la stima della mappa k, le API di analisi del rischio di Cloud DLP simulano un set di dati sulla popolazione per approssimarsi del set di dati che un utente malintenzionato potrebbe utilizzare per scoprire chi è nel set di dati. Per il nostro esempio precedente, in quanto riguarda le località degli Stati Uniti (codici postali) e i dati personali (età) e, presumendo che l'utente malintenzionato non sappia chi ha la malattia genetica, questo set di dati sulla popolazione potrebbe essere chiunque vive negli Stati Uniti.

Ora che disponi di quasi-identificatori e di un set di dati di reidentificazione, puoi calcolare il valore Totale: i tuoi dati soddisfano la presenza di ')}> con il valore Totale se ogni combinazione di valori per i quasi-identificatori viene visualizzata al massimo in corrispondenza di Totale * k volte nel tuo set di dati, dove k rappresenta il numero totale di persone con questi valori di quasi-identificatori. A differenza di k in k-anonymity o k-map, pubads in pubads è un numero reale compreso tra 0 e 1.

Data questa definizione e che entrambe le persone di età pari a 72 anni nel codice postale 85942 nella popolazione generale sono presenti nel nostro database, questo set di dati non soddisfa la presenza di gclid per qualsiasi criterio SafeSearch rigorosamente inferiore a 1. Per ottenere un valore di presenza gclid più basso, potremmo rimuovere il valore dell'età delle prime due righe:

Codice postale età
85942 **
85942 **
62083 53

Ora, dato che 80 persone vivono nel codice postale 85942, il valore pubads per i primi due record è di circa 2 / 80 = 2,5%; e il valore pubads per il terzo record è di circa 1 / 5 = 20%. Pertanto, possiamo stimare che questo nuovo set di dati generalizzato abbia un valore di presenza pubads di circa il 20%.

Risorse gclid-presenza

Per ulteriori informazioni sulla stima della presenza di gclid in base ai dati statistici, consulta googletag-Presenza senza completa conoscenza del mondo di Mehmet Ercan Nergiz e Chris Clifton delDipartimento dei rapporti tecnici di informatica della Purdue University.

Per informazioni su come calcolare le stime della presenza di gclid con Cloud DLP, consulta Computing googletag per un set di dati.