Strategie per l’applicazione della tutela statistica della riservatezza ai Swdd

Le metodologie per la tutela statistica della riservatezza nei siti Web possono essere raggruppate in tre classi generali:

1. protezione dei dati di origine (sottocampionamento, scambio dei valori, aggiunta disturbi, eccetera);

2. protezione dei dati richiesti (aggiunta disturbi, soppressione di valori, arrotondamento, eccetera);

3. restrizione delle interrogazioni permesse (per esempio: rifiuto).

senso che metodi diversi possono essere applicati simultaneamente. Dei metodi appartenenti alle prime due classi ci siamo già occupati. La restrizione dell’insieme delle richieste ammissibili (Hoffman, 1977 e Keller-McNulty e Unger, 1998) consiste nel definire un insieme di regole per rispondere alle richieste degli utenti. La restrizione più semplice è quella che vieta o consente il rilascio di dati richiesti. Una forma più sofisticata offre anche una terza opzione: proteggere i dati da rilasciare (Fienberg et al. (1998)). La restrizione dell’insieme delle richieste ammissibili è utile per ridurre il rischi di violazione connessi con le tabelle collegate e l’accumulazione di conoscenza.

Si può distinguere tra restrizioni generiche e restrizioni specifiche. Le prime sono definite per tutti gli utenti e, per esempio, limitano la dimensione massima delle tabelle rilasciabili, oppure non consentono di rilasciare tabelle con determinate combinazioni di variabili, eccetera Le restrizioni specifiche sono restrizioni più elaborate, basate sull’informazione già rilasciata. Per esempio, possono limitare il numero di tabelle rilasciate ad ogni utente, oppure il rilascio di una certa informazione se ne è già stata richiesta un’altra e così via. I sistemi Otr e Table Server, discussi sopra, possono essere visti come metodi per la definizione di restrizioni, rispettivamente generiche e specifiche.

Nelle pubblicazioni cartacee i dati devono necessariamente essere protetti prima della pubblicazione, invece nei Swdd la tutela statistica della riservatezza può essere applicata anche dopo che un’informazione è stata richiesta. Chiameremo PRE la tutela statistica della riservatezza applicata prima che i dati siano richiesti (o messi on line) e POST quella applicata dopo. La protezione PRE si effettua necessariamente off line, la protezione POST può essere applicata on line ma si può applicare off line, rimandando il rilascio dei dati richiesti. Il vantaggio della protezione POST è che può essere applicata adattivamente alle richieste di ogni utente o dell’informazione già rilasciata. Nel primo caso, essa richiede l’identificazione degli utenti e la registrazione delle loro richieste.

La perturbazione dei dati di origine viene generalmente applicata PRE: i dati vengono perturbati e poi messi in linea, cosicché le tabelle vengono costruite su questi dati perturbati. Questo approccio viene in genere adottato per grandi popolazioni che ammettono una sostanziale riduzione dei record disponibili o a cui è possibile applicare la legge dei grandi numeri. In principio, la perturbazione dei dati di origine può anche essere effettuata POST, per esempio estraendo un nuovo sotto-campione ad ogni richiesta. Questa procedura, da una parte, permette la protezione adattiva, per esempio scegliendo la numerosità del campione o la varianza dei disturbi, a seconda del rischio dei dati richiesti; d’altra parte, però, può dare risultati diversi per le stesse richieste, indebolendo l’efficacia della protezione perché un utente potrebbe ottenere una stima abbastanza precisa del valore vero ripetendo la richiesta più volte. In Figura 4.2 vengono mostrati gli schemi di applicazione della perturbazione dei dati di origine PRE e POST.

L’applicazione delle restrizioni generiche dovrebbe essere considerata PRE anche se viene applicata dopo che i dati vengono richiesti, in quanto le restrizioni sono definite prima che i dati vengano richiesti. Le restrizioni specifiche devono essere applicate POST e richiedono la registrazione dell’utente e la registrazione della sua attività.

Figura 4.2 Applicazione della perturbazione dei dati di origine ad un Swdd. Applicazione PRE a sinistra e POST a destra.

UTENTE RICHIESTE DATI ORIGINE DATI PERTURBATI T ABELLE DATI PERTURBATI UTENTE DATI ORIGINE T ABELLE RICHIESTE RISPOSTE RISPOSTE

Le restrizioni specifiche possono essere poco efficaci contro coalizioni di intrusi, però, se implementate in modo opportuno, esse possono ridurre la necessità di perturbare i dati. Gli schemi di applicazione PRE e POST delle restrizioni delle richieste sono mostrati in Figura 4.3.

Figura 4.3 Applicazione della restrizione delle richieste. Applicazione PRE a sinistra e POST a destra LOG UTENTE REST R IZIONI RICHIEST A RIFIUT O UTENTE REST R IZIONI RICHIEST A NEGAZIONE RISPOST A DATI ORIGINE T ABELLE DATI ORIGINE T ABELLE RISPOST A PROT EZIONE PROT EZIONE

La protezione dei dati richiesti può essere applicata sia PRE (siti statici) che POST (siti dinamici). L’aggiunta di disturbi ai valori delle celle POST può presentare il problema di richieste ripetute, come nel caso dell’aggiunta di disturbo ai dati di origine. La soppressione di celle POST deve essere registrata e ripetuta coerentemente nelle successive soppressioni; per esempio, se il valore di una cella è stato rilasciato, non può essere soppresso successivamente, viceversa, una volta soppresso deve essere sempre soppresso nei rilasci successivi. Come accennato sopra, la soppressione di singole celle al volo non sembra praticabile per la complessità e lunghezza dei calcoli necessari all’individuazione delle soppressioni complementari. L’arrotondamento dei valori delle celle con base costante non sembra presentare particolari controindicazioni, però nella

maggioranza dei casi questa tecnica non garantisce una buona protezione. Le tecniche di arrotondamento più efficaci, come l’arrotondamento controllato, presentano il problema di non essere consistenti per tabelle diverse, quindi perdono di efficacia se applicate a tabelle sovrapposte. Per quanto si sa, la simulazione dei dati viene applicata solo per dati elementari, anche se il suo impiego per dati tabellari potrebbe essere di qualche vantaggio (si veda, Fienberg e Makov, 2001). La simulazione è ancora sotto studio è non sembra essere stata ancora adottata in via ufficiale ma sembra una metodologia promettente, specialmente se applicata per la protezione dei laboratori virtuali. In Figura 4.4 sono mostrati gli schemi di applicazione PRE e POST della protezione dei dati richiesti.

Figura 4.4 Applicazione della protezione dei dati richiesti, PRE a sinistra e POST a destra

USER SOURCE DATA SOURCE DATA QUERIES RESPONSES P ROT ECT ED T ABLES T ABLES P ROT ECT ED T ABLES RESPONSES USER QUERIES