Aplicación de la técnica de K-anonimización sobre bases de datos relacionales

UNIVERSIDAD DE VALLADOLID APLICACI ´ ON DE LA T´ ECNICA DE K-ANONIMIZACI ´ ON SOBRE BASES DE DATOS RELACIONALES ESCUELA DE INGENIER´ IA INFORM ´ ATICA MENCI ´ ON TECNOLOG´ IAS DE LA INFORMACI ´ ON TRABAJO DE FIN DE GRADO Alumna: Silvia Olmos Lara Tutora: Mercedes Mart´ınez Gonz´alez Agradecimientos Me gustar´ıa dedicarle unas palabras a todas las personas que me han ayudado durante estos cuatro a˜nos de carrera. A mi tutora Mercedes, por su confianza, dedicaci´on y apoyo durante estos meses. A Amador Aparicio, profesor y a David Sanz, responsable de privacidad de la UVa, por prestar su ayuda en todo lo posible. A todos los profesores que han formado parte de mi formaci´on acad´emica. A mis amigos y compa˜neros de carrera por amenizarme estos a˜nos de estudio. A mi familia, por su cari˜no y apoyo siempre. A mi pareja Tom´as por animarme diariamente. 3 Resumen La K-anonimizaci´on es una t´ecnica de anonimizaci´on que sirve para proteger la privacidad de fuentes de datos previniendo la reidentificaci´on de los individuos a los que corresponden dichos datos. En este trabajo se ha desarrollado una aplicaci´on de escritorio que permite a sus usuarios anonimizar conjuntos de datos utilizando el algoritmo Inc´ognito, un algoritmo que implementa esta t´ecnica y que promete una gran eficiencia al anonimizar fuentes de datos. La aplicaci´on se apoya en bases de datos relacionales, y se ha desarrollado aplicando la privacidad desde el dise˜no y teniendo en cuenta los requisitos habituales de usabilidad, ya que est´a pensada para que sea f´acil de utilizar para usuarios no expertos en K-anonimizaci´on. 5 Abstract K-anonymization is an anonymization technique that protect data privacy preventing the reidentification of the individuals to which such data corresponds. In this project, has been developed a desktop application that allows its users to anonymize data sets using Incognito algorithm, an algorithm that implements this technique and that promises great efficiency when anonymizing data sources. The application is supported by relational databases, and has been developed applying privacy by design and taking into account the usual usability requirements, since it is designed to be easy to use for non-experts in K-anonymization users. 7 ´ Indice general Agradecimientos 3 Resumen 5 Abstract 7 1. Introducci´on 13 1.1. Contexto .......................................... 13 1.2. Motivaci´on ......................................... 14 1.3. Objetivos .......................................... 14 1.4. Organizaci´on de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2. Planificaci´on del proyecto 17 2.1. Planificaci´oninicial..................................... 17 2.2. Planderiesgos ....................................... 19 2.3. Presupuesto......................................... 20 3. Fundamentos te´oricos 21 3.1. La privacidad y la anonimizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Tiposdeatributos ..................................... 22 3.3. K-anonimizaci´on ...................................... 22 3.4. M´etodos de k-anonimizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.5. Propiedades de generalizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.6. Inc´ognito .......................................... 26 3.7. Debilidades de la K-anonimizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7.1. Ataque de coindidencias sin ordenar . . . . . . . . . . . . . . . . . . . . . . . 29 3.7.2. Ataque de publicaci´on complementaria . . . . . . . . . . . . . . . . . . . . . . 29 3.7.3. Ataquetemporal.................................. 30 9 CAP´ ITULO 1. INTRODUCCI ´ ON 16 Cap´ıtulo 2 Planificaci´on del proyecto En este cap´ıtulo se realiza la planificaci´on del proyecto necesaria antes de comenzar a trabajar en el mismo. Primero se detalla una planificaci´on inicial en la cual se indican las distintas tareas y el tiempo que llevar´a cada una de ellas. Despu´es, se analizan los distintos riesgos que pueden aparecer a lo largo del trabajo y hacer peligrar la planificaci´on inicial y por tanto el proyecto. Por ´ultimo, se indica una estimaci´on del presupuesto necesario para llevar a cabo este proyecto. 2.1. Planificaci´on inicial Para la planificaci´on del proyecto se va a seguir una metodolog´ıa de cascada, en la cual se desarrolla el proyecto de forma secuencial, dividi´endolo en distintas fases y desarroll´andolas en orden. Es decir, cada fase no podr´a comenzar hasta que la anterior no haya finalizado completamente. En cada una de las fases entrar´a no solo el desarrollo de las tareas indicadas, si no tambi´en la realizaci´on de las secciones de la memoria correspondientes. Las fases que se seguir´an en este proyecto ser´an: 1. Iniciaci´on: Durante esta fase se estudiar´an los conceptos te´oricos necesarios y se realizar´a la planificaci´on completa necesarios para la realizaci´on del proyecto. 2. An´alisis: En esta fase se realizar´a el estudio de los requisitos que tiene que deber´ıa cumplir el proyecto y se detallar´an todos los posibles casos de uso. 3. Dise˜no: Para esta fase se realizar´an varios diagramas que detallar´an como estar´a dise˜nada la aplicaci´on. Se realizar´a un modelo de dominio, un modelo conceptual y l´ogico para la base de datos, un diagrama de paquetes, uno de despliegue y alg´un diagrama de secuencia que se considere necesario para los procedimientos m´as complejos. Tambi´en se har´a un estudio de los patrones que tendr´a que cumplir la aplicaci´on. 4. Implementaci´on: Durante esta fase se desarrolla la aplicaci´on. Ser´a la fase m´as larga ya que es una tarea que consta de varias partes, en primer lugar un per´ıodo de aprendizaje de la tecnolog´ıa a utilizar, posteriormente la realizaci´on de la interfaz con su funcionalidad, y para finalizar la implementaci´on de los algoritmos. 5. Pruebas: Durante esta fase se comprobar´a que la aplicaci´on funciona correctamente y que los resultados obtenidos son los deseados. Para esto se utilizar´an otras herramientas similares validadas por la AEPD (Agencia Espa˜nola de Protecci´on de Datos) y se comprobar´an los 17 CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO resultados. Al finalizar este per´ıodo de validaci´on, se realizar´a unas comprobaciones finales de todas las fases del proyecto. Las fechas de inicio y finalizaci´on del proyecto se detallan a continuaci´on, as´ı como las distintas tareas a realizar con sus respectivas estimaciones de duraci´on (Tabla 2.1). La duraci´on total del proyecto es de 21 semanas, sin embargo la planificaci´on de las tareas se realiza en 20 semanas, dejando as´ı una semana de margen para posibles imprevistos. Fecha de inicio: 1 de Febrero Fecha de finalizaci´on: 27 de Junio Duraci´on del proyecto: 21 semanas El diagrama de Gantt correspondiente a la planificaci´on inicial del proyecto se detalla en la figura 2.1. En este diagrama se puede observar que todas las tareas tienen una relaci´on de dependencia de fin a inicio con sus predecesoras, es decir, cada tarea no podr´a comenzar hasta que la anterior haya finalizado. Tarea Duraci´on Fecha inicio Fecha fin 1 Lectura y asimilaci´on de conceptos te´oricos 1 semana 1/2/21 7/2/21 2 Planificaci´on 1 semana 8/2/21 14/2/21 3 Fundamentos te´oricos 1 semana 15/2/21 21/2/21 4 Recolecci´on de requisitos 1 semana 22/2/21 28/2/21 5 Realizaci´on de casos de uso 1 semana 1/3/21 7/3/21 6 Dise˜no 2 semanas 8/3/21 21/3/21 7 Implementaci´on 10 semanas 22/3/21 23/5/21 8 Pruebas 2 semanas 31/5/21 13/6/21 9 Introducci´on, conclusiones y resumen 1 semana 14/6/21 20/6/21 Tabla 2.1: Planificaci´on del proyecto Figura 2.1: Diagrama de Gantt inicial 18 CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO Como se puede ver en el diagrama de la figura 2.1 la tarea que m´as tiempo requiere es la de implementaci´on que consta de unas 10 semanas. Adem´as de por los motivos explicados anteriormente, el per´ıodo de tiempo de esta tarea coincide con la realizaci´on de las pr´acticas externas en empresa por parte del trabajador, por lo que este tendr´a menos tiempo disponible para la realizaci´on del trabajo. 2.2. Plan de riesgos En esta secci´on se realiza un an´alisis de los distintos riesgos que nos podremos encontrar a la hora de llevar a cabo la planificaci´on. En primer lugar se identificar´an los distintos riesgos que podr´ıan surgir. Despu´es, se analizar´a su exposici´on utilizando una matriz de riesgos por frecuencia e impacto. Por ´ultimo, se realizar´an los distintos planes de contingencia para aquellos riesgos que tengan una exposici´on alta. Para realizar el an´alisis de los riesgos y calcular su exposici´on utilizaremos la matriz de riesgos que se muestra en la tabla 2.2, valorando la frecuencia en una escala del 1 al 5, de menor a mayor probabilidad de ocurrencia y el impacto con la misma escala dependiendo del da˜no que provocar´ıa al proyecto si el riesgo llegara a producirse. Frecuencia 5 Alta Alta Muy alta Muy alta Muy alta 4 Media Media Alta Muy alta Muy alta 3 Baja Media Media Alta Muy alta 2 Baja Baja Media Media Alta 1 Baja Baja Baja Media Alta 1 2 3 4 5 Impacto Tabla 2.2: Matriz de riesgos Los riesgos identificados y su an´alisis se muestran en la tabla 2.3. Una vez realizado este an´alisis y en base a la exposici´on de cada riesgo se pueden tomar distintas decisiones. Si la exposici´on es baja se tiene la opci´on de simplemente aceptar el riesgo. Si la exposici´on es m´as alta, hay dos posibilidades, o realizar un plan de prevenci´on previo a su aparici´on, evitando el riesgo o reduci´endolo, o un plan de contingencia posterior a su aparici´on transfiriendo este riesgo a otra persona o mitig´andolo buscando una soluci´on para que el riesgo provoque los menores da˜nos posibles. Si se considera necesario se puede llevar a cabo ambos planes para un mismo riesgo. El plan de riesgos se muestra en la tabla 2.4. 19 CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO Riesgo Frecuencia Impacto Exposici´on Ordenador de trabajo estropeado 1 5 Alta Errores de tiempo de planificaci´on 5 3 Muy alta Enfermedad del trabajador 2 5 Alta Modificaci´on de requisitos 2 3 Media Uso de tecnolog´ıas desconocidas 4 2 Media Encontrar un fallo de dise˜no tard´ıo 2 5 Alta Recursos necesarios inaccesibles 2 4 Media Cambios en la carga de otros trabajos 4 5 Muy alta Tabla 2.3: An´alisis de riesgos Riesgo Plan Ordenador de trabajo estropeado Reducir el riesgo realizando copias de seguridad y mitigar el riesgo utilizando otro ordenador Errores de tiempo de planificaci´on Evitar el riesgo introduciendo un margen de tiempo en la planificaci´on Enfermedad del trabajador Reducir el riesgo introduciendo un margen de tiempo en la planificaci´on Modificaci´on de requisitos Reducir el riesgo dedicando m´as tiempo al an´alisis de requisitos Uso de tecnolog´ıas desconocidas Evitar el riesgo aumentando el tiempo de aprendizaje sobre las tecnolog´ıas Encontrar un fallo de dise˜no tard´ıo Reducir el riesgo realizando revisiones junto al tutor frecuentemente Recursos necesarios inaccesibles Buscar otros que los sustituyan Cambios en la carga de otros trabajos Replanificar las tareas Tabla 2.4: Plan de riesgos 2.3. Presupuesto En esta secci´on se calcular´a el presupuesto necesario para realizar el proyecto teniendo en cuenta los gastos del personal y los gastos de los productos que se utilizar´an. El gasto de productos ser´a de 0€, ya que el hardware necesario para realizar el proyecto es una computadora normal, sin ninguna caracter´ıstica necesaria, por lo tanto, se utilizar´a el equipo personal del desarrollador. En cuanto a los gastos de software se utilizar´a ´unicamente servicios gratuitos. El gasto de personal tambi´en ser´a de 0€ya que el desarrollador no cobrar´a por la realizaci´on del proyecto. Sin embargo, podemos estimar el costo que supondr´ıa si el desarrollador cobrara por su trabajo. El salario medio de un programador junior en Espa˜na es de 18.000 €al a˜no [29], en una jornada de 40 horas a la semana, es decir 160 horas al mes, 1920 horas al a˜no, por lo tanto, el sueldo de un programador es de aproximadamente 10€/hora. La estimaci´on de tiempo que llevar´a el proyecto ser´a de 300 horas. Entonces el gasto de personal y tambi´en el gasto total del proyecto ser´ıa de 3000€. 20 Cap´ıtulo 3 Fundamentos te´oricos En este cap´ıtulo se detallar´an los principales conceptos que hay que conocer para entender como funciona la t´ecnica de K-anonimizaci´on. Adem´as, tambi´en se explicar´a como funciona el algoritmo Inc´ognito, uno de los algoritmos de K-anonimizaci´on m´as populares y el que se implementar´a en este proyecto. [17] Para la mejor comprensi´on de esta secci´on se pondr´an ejemplos que partir´an de la tabla 3.1. Esta tabla contiene datos personales en los cuales se ha eliminado cualquier atributo que pueda identificar a la persona. Son datos m´edicos en los que se indica el c´odigo postal en el que vive un individuo, la edad que tiene y si tiene problemas de colesterol alto o no. Esta tabla contiene el dato sensible del colesterol el cual querremos proteger para que no se pueda identificar si cierta persona tiene este problema o no a partir de los otros atributos de la tabla. C´odigo postal Edad Colesterol 37003 40 S 28108 44 S 24700 37 N 24700 37 N 37003 44 S 28108 40 S Tabla 3.1: Tabla de ejemplo 3.1. La privacidad y la anonimizaci´on Seg´un la RAE la privacidad es el ”´ambito de la vida privada que se tiene derecho a proteger de cualquier intromisi´on”. Es un derecho fundamental de las personas y por tanto es muy importante mantenerlo en cualquier ´ambito. Actualmente, en la era digital, la privacidad es una gran preocupaci´on para las personas, ya que gracias a internet la circulaci´on de datos personales ha aumentado de manera abismal. Para mantener esta privacidad existen gran cantidad de t´ecnicas de anonimizaci´on o seudonimizaci´on de los datos. 21 CAP´ ITULO 3. FUNDAMENTOS TE ´ ORICOS Seg´un la AEPD la anonimizaci´on es ”el proceso de eliminar o reducir al m´ınimo los riesgos de reidentificaci´on de los datos pero manteniendo la veracidad de los resultados de su tratamiento”, es decir, adem´as de evitar la identificaci´on de las personas por cualquier medio, los datos anonimizados deben garantizar que cualquier operaci´on o tratamiento que pueda ser realizado con posterioridad a la anonimizaci´on no conlleva una distorsi´on de los datos reales [24]. Seg´un el RGPD la seudonimizaci´on es ”el tratamiento de datos personales de manera tal que ya no puedan atribuirse a un interesado sin utilizar informaci´on adicional”. Normalmente se realiza modificando un atributo en un registro de datos por otro (un seud´onimo). Sin embargo, sigue existiendo una alta probabilidad de identificar a la persona de manera indirecta [11]. 3.2. Tipos de atributos En primer lugar, tenemos que distinguir los distintos tipos de atributos que puede tener una base de datos dependiendo de la informaci´on que contengan. Pueden ser [23]: Identificadores: Son los atributos que por si solos identifican al sujeto. P.ej: DNI, tel´efono, n´umero de la seguridad social, etc. Cuasi-identificadores: Son los atributos que si se agrupan con otros cuasi-identificadores pueden identificar a un sujeto. P.ej: edad, c´odigo postal, fecha de nacimiento, etc. Atributos sensibles: Son los atributos cuyos datos podr´ıan tener un gran impacto en la privacidad del sujeto. P.ej: Enfermedades, nivel de renta, tratamientos m´edicos, etc. 3.3. K-anonimizaci´on La K-anonimizaci´on es una t´ecnica que se utiliza para prevenir ataques donde la agregaci´on de datos permita la reidentificaci´on de las personas a partir de los datos recolectados de diferentes fuentes de los cuales se han eliminado los atributos que permiten la identificaci´on directa [14]. Fue propuesta por Latanya Sweeney en el a˜no 2002, con el objetivo de resolver el problema en el que dados unos datos estructurados personales se quiera garantizar de manera cient´ıfica que en una nueva versi´on de estos no se pueda reidentificar a las personas, y adem´as, los datos sigan siendo ´utiles en la pr´actica [31]. La K-anonimidad es la propiedad de los datos anonimizados que permite cuantificar hasta qu´e punto se preserva la anonimidad de los sujetos presentes en un conjunto de datos en el que se han eliminado los identificadores. Dicho de otro modo, es una medida del riesgo de que agentes externos puedan obtener informaci´on de car´acter personal a partir de datos anonimizados [23]. 22 CAP´ ITULO 3. FUNDAMENTOS TE ´ ORICOS Toda relaci´on tiene un conjunto de frecuencias, esto es, la cantidad de registros que toman el valor de cada combinaci´on de atributos cuasi-identificadores. Por ejemplo, a partir de la tabla 3.1, la frecuencia para c´odigo postal = 24700, edad = 37, y colesterol = N es 2, ya que hay dos registros que toman estos valores. La frecuencia para c´odigo postal = 37003 y edad = 40 es 1. Cuando decimos que una cierta relaci´on es K-an´onima, nos referimos a que cumple con la propiedad de k-anonimato, es decir, cada valor en el conjunto de frecuencias de esta relaci´on es mayor o igual que K. La tabla 3.1 es 1-an´onima para el conjunto de atributos cuasi-identificadores compuesto por c´odigo postal y edad. Un conjunto de datos 1-an´onimo significa que alg´un conjunto de datos de los atributos cuasi-identificadores aparece ´unicamente en una tupla, por lo tanto, es posible identificar al individuo. Es decir, estos datos no son an´onimos [23]. 3.4. M´etodos de k-anonimizaci´on Para implementar la K-anonimizaci´on se pueden utilizar dos m´etodos que no introducen perturbaci´on en los datos, es decir, no introducen informaci´on err´onea en los datos originales si no que logran la protecci´on mediante la sustituci´on de los valores originales por otros m´as generales. Estos m´etodos son [23]: Generalizaci´on: consiste en modificar los valores de los atributos cuasi-identificadores para que sean menos precisos, mediante rangos para valores num´ericos o mediante jerarqu´ıas para valores nominales. La generalizaci´on puede ser global si siempre se realiza de la misma manera la transformaci´on para los distintos registros de un mismo tipo de atributo, o local si se utilizan diferentes criterios para cada registro. Supresi´on: consiste en eliminar algunos registros de los datos cuyos valores se encuentran en un rango muy distinto al de los valores de otros registros. De esta manera no se distorsionan los resultados al realizar la generalizaci´on. Sin embargo, este m´etodo se utiliza con poca frecuencia ya que genera una gran p´erdida de informaci´on y por lo tanto s´olamente se aplican a valores que no son relevantes para la finalidad del tratamiento. Por ejemplo, si tenemos unos datos con un registro de edades de personas, y la mayor´ıa de ellas se encuentran en un rango entre 30-35 podr´ıamos generalizar los valores con este rango. Sin embargo, si un registro tuviese un valor de 60 no podr´ıamos separar la generalizaci´on de los datos en dos rangos como 30-35 y 60-65 ya que para el segundo rango ´unicamente tenemos un valor y se podr´ıa identificar al individuo. Si quisi´eramos incluir todos los valores dentro de la misma generalizaci´on quedar´ıa un rango de 30-60, lo que crea una p´erdida de informaci´on bastante elevada. Por lo tanto, en este caso podr´ıamos suprimir el valor de la persona de 60 a˜nos y dejar el resto de valores dentro de la generalizaci´on 30-35. 23 CAP´ ITULO 3. FUNDAMENTOS TE ´ ORICOS En las tablas que se muestran a continuaci´on se pueden ver distintos ejemplos de las t´ecnicas explicadas. En la tabla 3.2 vemos un ejemplo de generalizaci´on global sobre los atributos c´odigo postal y edad, en los cuales todos sus valores est´an generalizados. Sin embargo, en la tabla 3.3 se muestra un ejemplo de generalizaci´on local sobre el atributo c´odigo postal. En este caso algunos valores est´an generalizados y otros no, ya que si se quiere que los datos cumplan una 2-anonimidad es suficiente con generalizar los datos de esta manera. De esta manera, sin generalizar todos los datos se pierde una menor cantidad de informaci´on. Por ´ultimo en la tabla 3.4 se muestra un ejemplo de supresi´on en el cual las dos ´ultimas tuplas ser´an suprimidas ya que el valor del atributo edad en ambos casos y el valor del c´odigo postal en la ´ultima tupla tienen valores que se escapan de los rangos que se siguen en resto de tuplas. Por lo tanto, se suprimir´an para no perder la precisi´on. C´odigo postal Edad Colesterol 37*** 40-49 S 28*** 40-49 S 24*** 30-39 N 24*** 30-39 N 37*** 40-49 S 28*** 40-49 S Tabla 3.2: Ejemplo de generalizaci´on global C´odigo postal Edad Colesterol 37*** 40-49 S 28*** 40-49 S 24700 30-39 N 24700 30-39 N 37*** 40-49 S 28*** 40-49 S Tabla 3.3: Ejemplo de generalizaci´on local C´odigo postal Edad Colesterol 37003 40 S 28108 44 S 24700 37 N 24700 37 N 37003 44 S 28108 40 S 37891 33 N 50011 13 S Tabla 3.4: Ejemplo de supresi´on 24 CAP´ ITULO 3. FUNDAMENTOS TE ´ ORICOS 3.5. Propiedades de generalizaci´on Antes de explicar el algoritmo que se va a implementar en este proyecto, hay que mencionar tres propiedades que juegan un papel imprescindible en este. Estas son [17]: Propiedad de generalizaci´on: Tenemos dos conjuntos de atributos P y Q de una misma relaci´on, siendo Q una generalizaci´on de P. Si la relaci´on es k-an´onima con respecto a P, entonces tambi´en lo es con respecto a Q. Ejemplo: Teniendo los conjuntos de atributos, P y Q (tablas 3.6 y 3.7), de una misma relaci´on (tabla 3.5), siendo Q una generalizaci´on de P. Sabemos que la relaci´on es 1-an´onima con respecto a P, por lo tanto tambi´en ser´a 1-an´onima con respecto a Q. Propiedad de resumen: Tenemos dos conjuntos de atributos P y Q de una misma relaci´on, siendo Q el mismo conjunto que P o una generalizaci´on de P. Si tenemos f1, el conjunto de frecuencias de la relaci´on con respecto a P, podemos generar f2, el conjunto de frecuencias de la relaci´on con respecto a Q, sumando f1 con cada conjunto de valores de Q. Ejemplo: Teniendo los conjuntos de atributos, P y Q (tablas 3.6 y 3.7), de una misma relaci´on (tabla 3.5), siendo Q una generalizaci´on de P. Sabemos que el conjunto de frecuencias de la relaci´on con respecto a P, f1, es [1,1,1,1,1]. Si unimos Q con f1 (tabla 3.8) y sumamos los valores de f1 agrupando por cada conjunto de valores distinto de Sexo y Z1, tenemos que f2, el conjunto de frecuencias de la relaci´on con respecto a Q es [2,1,1,1]. Propiedad del subconjunto: Teniendo P un conjunto de atributos de la relaci´on. Si la relaci´on es K-an´onima con respecto a P, entonces tambi´en lo es con respecto a cualquier conjunto de atributos T, tal que T sea un subconjunto de P. Ejemplo: Teniendo P (tabla 3.6), un conjunto de atributos de la relaci´on. Sabemos que la relaci´on es 1-an´onima con respecto a P, por lo tanto tambi´en lo ser´a con respecto al conjunto de atributos de [Sexo] y [C´odigo postal]. Sexo C´odigo postal Colesterol M 53715 S M 53710 N F 90210 S M 02174 S F 02237 N Tabla 3.5: Ejemplo de relaci´on Sexo C´odigo postal M 53715 M 53710 F 90210 M 02174 F 02237 Tabla 3.6: Conjunto de atributos P Sexo Z1 M 5371* M 5371* F 9021* M 0217* F 0223* Tabla 3.7: Conjunto de atributos Q Sexo Z1 f1 M 5371* 1 M 5371* 1 F 9021* 1 M 0217* 1 F 0223* 1 Tabla 3.8: Uni´on de Q con f1 25 CAP´ ITULO 4. HERRAMIENTAS QUE APLICAN LA K-ANONIMIZACI´ ON Por ´ultimo se puede seleccionar una generalizaci´on concreta con el bot´on derecho del rat´on e indicar ’Apply transformation’ para anonimizar los datos con la generalizaci´on seleccionada (figura 4.3). Una vez que tenemos estos datos anonimizados, se pueden exportar a un fichero CSV. Figura 4.1: Interfaz gr´afica de usuario de ARX Figura 4.2: Grafo de las posibles generalizaciones de ARX Figura 4.3: Datos anonimizados con ARX 32 CAP´ ITULO 4. HERRAMIENTAS QUE APLICAN LA K-ANONIMIZACI´ ON 4.2. Amnesia Amnesia es una herramienta para anonimizar datos personales y confidenciales. Esta herramienta tiene tanto versi´on de escritorio como versi´on online. Para este proyecto ´unicamente se prob´o la versi´on online. Anmesia permite importar datos desde un fichero de texto (figura 4.4). Cuando se selecciona el fichero desde el que se quieren importar los datos la herramienta solicita indicar cual es el delimitador que separa los datos y cuales son los tipos de estos datos (string, int, decimal...). Tambi´en permite marcar los atributos que queremos mantener para la anonimizaci´on y desmarcar aquellos que queremos desechar. Para aplicar el algoritmo de K-anonimizaci´on se dejar´ıan sin marcar los atributos identificadores. (figura 4.5) Para indicar las distintas jerarqu´ıas, Amnesia no permite incluir expl´ıcitamente cual es la jerarqu´ıa que se quiere utilizar, si no que ´unicamente permite autogenerarlas desde la propia aplicaci´on, solicitando algunos detalles. Para atributos de tipo string permite utilizar una jerarqu´ıa basada en m´ascara, es decir, a˜nadiendo asteriscos a los ´ultimos caracteres de la cadena, o basada en grupo, sustituyendo los diferentes valores por otro string. Para atributos de tipo num´erico permite utilizar jerarqu´ıas basadas en rango, agrupando los n´umeros en rangos de x valores, o sustituyendo ciertos valores por otro n´umero. En la figura 4.6 se puede ver una jerarqu´ıa basada en rango generada por Amnesia para datos num´ericos. Una vez indicados todos estos par´ametros, la aplicaci´on solicita que se enlacen los atributos con sus jerarqu´ıas correspondientes y que se indique el valor de K deseado, lo que genera el grafo de posibles generalizaciones, como se puede ver en la figura 4.7. Por ´ultimo, para anonimizar los datos con la generalizaci´on deseada solamente hay que seleccionar esta en el grafo y se genera la tabla con los datos anonimizados con la generalizaci´on indicada. Los datos anonimizados se puede exportar tambi´en a un fichero de texto. En la figura 4.8 se puede ver el resultado que proporciona Amnesia al finalizar el procedimiento de anonimizaci´on. En la parte izquierda de la pantalla se muestran los datos iniciales sin anonimizar y en la parte izquierda los datos anonimizados. 33 CAP´ ITULO 4. HERRAMIENTAS QUE APLICAN LA K-ANONIMIZACI´ ON Figura 4.4: Importar datos desde Amnesia Figura 4.5: Indicar tipo de datos Amnesia 34 CAP´ ITULO 4. HERRAMIENTAS QUE APLICAN LA K-ANONIMIZACI´ ON Figura 4.6: Jerarqu´ıa de generalizaci´on con Amnesia Figura 4.7: Grafo de resultados de Amnesia 35 CAP´ ITULO 4. HERRAMIENTAS QUE APLICAN LA K-ANONIMIZACI´ ON Figura 4.8: Datos anonimizados con Amnesia 36 Cap´ıtulo 5 An´alisis Durante la fase de an´alisis se especifica detalladamente todas las funcionalidades que debe tener el proyecto. En primer lugar recogen todos los requisitos que se deben cumplir necesariamente. Seg´un la IEEE un requisito es: ”Una condici´on o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado” [15]. Despu´es, se realizar´a un estudio de los diferentes casos de uso que el sistema deber´ıa llevar a cabo. 5.1. Requisitos funcionales Los requisitos funcionales son aquellas tareas que el sistema debe ser capaz de realizar. Los servicios que el sistema debe proporcionar, c´omo debe reaccionar a una entrada particular y c´omo debe comportarse ante situaciones particulares. El sistema debe ser capaz de anonimizar los datos de tal manera que no sea posible la reidentificaci´on de un sujeto. El sistema debe ser capaz de importar datos de un fichero a una base de datos relacional. El sistema debe permitir al usuario indicar los separadores de datos que usan los ficheros a importar. El sistema debe permitir que el usuario indique el tipo y la longitud de los datos (int, char, varchar...) El sistema debe realizar una propuesta de los tipos de los atributos cuasi-identificadores. El sistema debe permitir que el usuario indique los tipos de los atributos. (cuasi-identificadores y identificadores o sensibles) El sistema debe realizar una propuesta de jerarqu´ıa de generalizaci´on para los atributos de tipo entero. El sistema debe permitir al usuario indicar la jerarqu´ıa de generalizaci´on de cada atributo. 37 CAP´ ITULO 5. AN´ ALISIS El sistema debe permitir al usuario que indique el grado de k-anonimato deseado. El sistema debe permitir que el usuario indique en que atributos quiere aplicar supresi´on. El sistema debe ser capaz de calcular las posibles combinaciones de generalizaci´on k-an´onimas con un valor de k determinado. El sistema debe ser capaz de calcular la combinaci´on de generalizaci´on ´optima para cada valor de k. El sistema debe permitir que el usuario indique la combinaci´on de generalizaci´on que desea que se aplique para anonimizar los datos. El sistema debe ser capaz de K-anonimizar los datos para cualquier generalizaci´on posible. El sistema debe permitir exportar los datos anonimizados. El sistema ser´a capaz de crear archivos de configuraci´on de las jerarqu´ıas de los atributos. El sistema ser´a capaz de importar los archivos de configuraci´on de las jerarqu´ıas de los atributos. El sistema ser´a capaz de crear archivos de configuraci´on para los tipos de los atributos (int, char, varchar, boolean...) y su longitud. El sistema ser´a capaz de cargar archivos de configuraci´on para los tipos de los atributos (int, char, varchar, boolean...) y su longitud. El sistema deber´a tener una interfaz f´acil de usar para usuarios no expertos en K-anonimizaci´on. 5.2. Requisitos no funcionales Los requisitos no funcionales describen restricciones que afectan a los servicios o funciones del sistema. Es decir, describen c´omo debe realizar el sistema las diferentes tareas. El sistema deber´a soportar la codificaci´on UTF-8. El sistema deber´a usar bases de datos relacionales. El sistema deber´a importar ficheros en formato .txt y .csv El sistema deber´a exportar los datos anonimizados a ficheros en formato .txt y .csv El sistema debe permitir indicar al usuario el tipo (int, char,varchar...) y longitud de los datos tanto manualmente como utilizando un fichero de configuraci´on. El sistema debe permitir al usuario indicar la jerarqu´ıa de generalizaci´on de cada atributo tanto manualmente como utilizando un fichero de configuraci´on. 38 CAP´ ITULO 5. AN´ ALISIS 5.3. Requisitos de informaci´on Los requisitos de informaci´on indican el tipo de informaci´on que debe guardar el sistema. El sistema deber´a borrar todos los datos al finalizar la anonimizaci´on. El sistema almacenar´a durante el proceso de anonimizaci´on informaci´on del conjunto de datos sin anonimizar. El sistema almacenar´a durante el proceso de anonimizaci´on informaci´on de la jerarqu´ıa de generalizaci´on asociada a cada atributo. El sistema almacenar´a durante el proceso de anonimizaci´on los tipos de los atributos del conjunto de datos (sensibles, identificadores o no sensibles ni identificadores). El sistema almacenar´a durante el proceso de anonimizaci´on los atributos cuasi-identificadores. 5.4. Requisitos de seguridad y privacidad El sistema no guardar´a m´as datos de los necesarios. El sistema borrar´a todos los datos cuando el usuario termine el proceso de anonimizaci´on. El sistema comprobar´a que los datos realmente han sido eliminados tras borrarlos. El sistema realizar´a el borrado de los datos deber´a ser una operaci´on at´omica. El tratamiento deber´a estar registrado en el Registro de Actividades de Tratamiento de Datos Personales previsto en el art´ıculo 30 del RGPD. 39 CAP´ ITULO 5. AN´ ALISIS 5.5. Casos de uso En esta secci´on se indicar´a en primer lugar el diagrama de casos de uso del sistema propuesto. En este diagrama se representan las acciones que podr´a realizar el usuario en el sistema, las cuales ya han sido indicadas en el apartado de requisitos funcionales. Figura 5.1: Diagrama de casos de uso A continuaci´on se detallan los distintos casos de uso, describiendo la secuencia de actividades que el sistema, con la intervenci´on del usuario, debe realizar. 40 CAP´ ITULO 5. AN´ ALISIS UC-01 Importar datos Descripci´on El usuario selecciona un fichero para importar sus datos. Precondici´on El usuario debe disponer de un fichero .txt o .csv con los datos que quiere anonimizar. Secuencia normal 1. El usuario indica que quiere importar un fichero de datos. 2. El sistema le solicita al usuario que seleccione el fichero. 3. El usuario indica el fichero deseado. 4. El sistema solicita a usuario cual es el separador de los datos. 5. El usuario indica el separador. 6. El sistema solicita al usuario que elija si quiere indicar los tipos y tama˜no de los atributos mediante un fichero de configuraci´on o manualmente. 7. El usuario indica que quiere indicarlo manualmente. 8. El sistema muestra los nombres de los atributos. 9. El sistema solicita al usuario que indique los tipos y el tama˜no m´aximo de cada atributo de los datos a importar. 10. El usuario indica el tipo y el tama˜no m´aximo de cada atributo. 11. El usuario indica que quiere importar los datos con los par´ametros indicados 12. El sistema guarda los datos en la base de datos. 13. El sistema muestra una tabla con los datos importados. Flujos alternativos 7a. El usuario indica que quiere indicar los tipos y tama˜no m´aximo de los atributos mediante un fichero de configuraci´on. 7b. El sistema solicita al usuario que indique la ruta al fichero de configuraci´on. 7c. El usuario indica la ruta al fichero de configuraci´on y el caso de uso contin´ua en el paso 9. 10a. El usuario no esta conforme con alg´un par´ametro indicado y lo cambia. El caso de uso continua en el paso 11. Postcondici´on Los datos del fichero se han importad a la base de datos y se muestra la tabla al usuario. Tabla 5.1: Caso de uso: Importar fichero de datos UC-02 Indicar atributos identificadores y sensibles Descripci´on Se indican los atributos identificadores y sensibles Precondici´on Los datos a anonimizar est´an importados Secuencia normal 1. El sistema muestra los atributos de los datos importados. 2. El sistema solicita al usuario que marque los atributos que sean identificadores y los sensibles. 3. El usuario marca los atributos que identificadores y los sensibles. 4. El sistema actualiza los tipos de los atributos marcados. 5. El sistema actualiza el conjunto de posibles atributos cuasi-identificadores. Postcondici´on El sistema tiene guardados los atributos que son sensibles y los identificadores. Tabla 5.2: Caso de uso: Indicar atributos sensibles o identificadores 41 CAP´ ITULO 6. DISE˜ NO Figura 6.1: Modelo de dominio 6.2. Metamodelo de la base de datos En este caso en vez de realizar un modelo de la base de datos, se va a necesitar un metamodelo el cual debe cubrir cualquier caso, ya que se necesita guarda la informaci´on sobre el esquema de los datos adem´as de los propios datos. La base de datos que se va a tener va a contener distintas tablas que se ir´an creando cada vez que se importen unos datos nuevos, durante la configuraci´on de los diferentes par´ametros y mientras se procese el algoritmo. Estas tablas son necesarias ´unicamente para el funcionamiento del algoritmo, por lo que una vez este termine y el usuario importe otros datos o cierre la aplicaci´on se borrar´an todas las tablas de la base de datos. De esta manera nos aseguramos de no almacenar de manera persistente ning´un tipo de informaci´on sensible del usuario. Se necesitar´an distintas tablas que se crear´an din´amicamente dependiendo del n´umero de atributos que contengan los datos que introduzca el usuario y cuantos de estos se marquen como cuasi-identificadores. Por lo tanto, en est´a secci´on se describir´an las tablas gen´ericamente, describiendo un esquema general, pero teniendo en cuenta que este esquema variar´a dependiendo de los datos iniciales. 48 CAP´ ITULO 6. DISE˜ NO 6.2.1. Metamodelo conceptual Para realizar el metamodelo conceptual de la base de datos en primer lugar se identifican los tipos de entidades, es decir, los datos que hay que almacenar. Estos son: DATOS(atributo1, atributo2, atributo3...): Son los datos iniciales que el usuario quiere anonimizar, tiene N atributos dependiendo del fichero de datos que se importe. Los nombres de los atributos se modificar´an dependiendo de los datos especificados por el usuario. ATRIBUTOS(atributo, tipo): Son los atributos de los datos, estos pueden ser identificadores, cuasi-identificadores, sensibles. Si los atributos no son ninguno de los tipos anteriores se marcar´an como NSoI (no sensible o identificador), que se tomar´a como el tipo de atributos por defecto. JERARQU´ IA(nivel0, nivel1...): Guarda las jerarqu´ıas de generalizaci´on de los atributos. Habr´a tantas tablas de jerarqu´ıas como atributos tengan los datos a anonimizar y cada una de ellas contendr´a tantos niveles como posibles generalizaciones tenga el atributo. Llamaremos a cada una de las tablas Jerarquia atributo siendo atributo el nombre del atributo del que se almacena su jerarqu´ıa. NODO(ID, dim1, index1, dim2, index2...): Esta tabla representa los nodos de un grafo formado por las posibles generalizaciones que se pueden aplicar a los datos. El atributo ’ID’ es un identificador ´unico para cada nodo. ’Dimi’ representa el nombre del atributo al que se refiere ’indexi’, el cual almacena el nivel de generalizaci´on del atributo. Existir´an tantas tablas nodo como atributos cuasi-identificadores tengan los datos, ya que se comenzar´a creando un grafo con 1 ´unico atributo y se continuar´an a˜nadiendo de manera recursiva otros grafos con un atributo m´as cada vez, hasta tener el grafo con tantos atributos como cuasi-identificadores tengan los datos. A cada una de estas tablas las llamaremos Nodo x siendo x el n´umero de atributos que contiene ese nodo. En segundo lugar se analizar´ıan las relaciones que tienen estas entidades entre si. Las relaciones son: Contiene (Datos, Atributos): Los datos est´an compuestos por atributos. Pertenece (Jerarqu´ıa, Atributos): Una jerarqu´ıa pertenece a un atributo. Enlace (Nodo, Nodo): Los nodos se enlazan entre ellos formando un grafo. En siguiente lugar estudiamos las cardinalidades que tienen estas relaciones. card min(Datos, Contiene) = 1 card max(Datos, Contiene) = N Unos datos contienen 1 o m´as atributos. M´ınimo siempre tiene que tener un atributo, si no no habr´ıa nada que anonimizar. card min(Atributos, Contiene) = 1 card max(Atributos, Contiene) = 1 49 CAP´ ITULO 6. DISE˜ NO Un atributo est´a contenido en unos ´unicos datos que son los datos originales sin anonimizar, ya que son los ´unicos que se guardan. card min(Jerarqu´ıa, Pertenece) = 1 card max(Jerarqu´ıa, Pertenece) = 1 Una jerarqu´ıa pertenece a un ´unico atributo. card min(Atributos, Pertenece) = 1 card max(Atributos, Pertenece) = 1 Un atributo tiene una ´unica jerarqu´ıa de generalizaci´on. card min(Nodo, Enlace) = 1 card max(Nodo, Enlace) = N Un nodo se enlaza con varios nodos. M´ınimo siempre tendr´a un enlace ya que todo nodo siempre tendr´a alguna generalizaci´on o ser´a generalizaci´on de otro. Si no, no habr´ıa generalizaciones y no se podr´ıan anonimizar los datos. El modelo conceptual queda representado en la figura 6.2. Figura 6.2: Modelo conceptual de la base de datos 50 CAP´ ITULO 6. DISE˜ NO 6.2.2. Metamodelo l´ogico Para pasar del modelo conceptual al modelo l´ogico transformamos las entidades indicadas en el primero creando una tabla por cada entidad. Estas quedar´ıan de la siguiente forma: DATOS(atributo1, atributo2, atributo3...) ATRIBUTOS(atributo, tipo) JERARQU´ IA(nivel0, nivel1...) NODO(ID, dim1, index1, dim2, index2...) Despu´es procesamos las relaciones entre tablas indicadas. Para las relaciones uno a varios se absorbe el identificador hacia la tabla con cardinalidad m´axima uno. Para la relaci´on Contiene, tendr´ıamos que absorber el nombre del atributo hacia la tabla Datos, sin embargo, el nombre de los atributos ser´a sustituido en esta tabla por ’atributo1’,’atributo2’... Por lo tanto, no es necesario a˜nadir esto. Para las relaciones varios a varios generamos una tabla con el nombre de la relaci´on y los identificadores de las tablas que relacionan. ENLACE (start, end): Siendo ’start’ el id del nodo desde el que parte el enlace y ’end’ el id del nodo al que llega. Es decir, ’end’ es el id del nodo que representa una generalizaci´on del nodo cuyo id es ’start’. Las relaciones uno a uno las transformar´ıamos incluyendo todo en una misma tabla la cual quedar´ıa de la siguiente manera: ATRIBUTO(nombre, tipo, nivel0, nivel1...) Sin embargo, no todos los atributos tienen los mismos niveles de jerarqu´ıa, por lo tanto al no tener la misma estructura de la tabla no podremos incluir todos en la misma y habr´ıa que crear varias tablas. Para mayor facilidad para la aplicaci´on y ya que los tipos de los atributos se guardar´an en momentos distintos a las jerarqu´ıas. Mantendremos en una misma tabla todos los tipos de los atributos y crearemos varias tablas de Jerarqu´ıas para cada atributo nombrando a cada una de ellas con el atributo al que se refiere como ’jerarquia atributo’. Por lo tanto las tablas que nos quedan son las que se muestran en la figura 6.3. Figura 6.3: Modelo l´ogico de la base de datos 51 CAP´ ITULO 6. DISE˜ NO Ejemplo: Para una mayor comprensi´on de este modelo se va a incluir a continuaci´on un ejemplo de una posible instancia de la base de datos. Supongamos unos datos iniciales como los que se muestran en la tabla 6.1. En estos datos tenemos cuatro atributos: fnac, sexo, cod postal y dolencia. Si marcamos dolencia como atributo sensible y el resto como no sensible ni identificador (NSoI) la tabla de atributos quedar´ıa como se muestra en la tabla 6.2. Fnac Sexo Cod postal Dolencia 1986 M 53715 gripe 1996 F 53715 neumon´ıa 1986 M 53703 bronquitis 1986 M 53703 fractura brazo 1996 F 53706 apendicitis 1986 F 53706 fractura pierna Tabla 6.1: Instancia de datos atributo tipo fnac NSoI sexo NSoI cod postal NSoI dolencia sensible Tabla 6.2: Instancia de atributos Las jerarqu´ıas de generalizaci´on de los distintos atributos se muestran en las tablas 6.3, 6.4, 6.5. Como dec´ıamos en el apartado anterior, cada jerarqu´ıa puede tener una cantidad diferente de niveles. En este caso se muestran jerarqu´ıas de 2 o 3 niveles, pero una jerarqu´ıa puede tener cualquier n´umero de niveles. level 0 level 1 level 2 53706 5370* 537** 53715 5371* 537** 53703 5370* 537** Tabla 6.3: Instancia de Jerarqu´ıa cod postal level 0 level 1 level 2 1986 198* 19** 1996 199* 19** Tabla 6.4: Instancia de Jerarqu´ıa fnac level 0 level 1 M Persona F Persona Tabla 6.5: Instancia de Jerarqu´ıa sexo Si marcamos como atributos cuasi-identificadores a los atributos fnac y cod postal e indicamos un valor de k=3. Seg´un el algoritmo Inc´ognito se crear´ıa en primer lugar la tabla de nodos 1 compuesta por 1 atributo y sus posibles generalizaciones (tabla 6.6). Y la tabla de enlaces 1 se crear´ıa de manera que se genere un grafo lineal en el que cada nodo tiene como m´aximo un padre y un hijo (tabla 6.8). Para los distintos nodos en esta tabla se comprobar´ıa si se cumple la k-anonimidad, que en este caso es 3-anonimidad. Para el atributo fnac vemos que s´olamente se cumple esta propiedad cuando generalizamos al segundo nivel de la jerarqu´ıa. Por lo tanto, se crea la tabla de nodos 2 combinando las generalizaciones de fnac que cumplen la k-anonimidad con todas las posibles generalizaciones del siguiente atributo. De esta manera la tabla nodos 2 quedar´ıa como se muestra en la tabla 6.7 y sus enlaces son los mostrados en la tabla 6.9. Como ´unicamente tenemos dos atributos cuasi-identificadores s´olo se crear´an dos tablas de nodos y enlaces. A continuaci´on habr´ıa que comprobar que nodos de la tabla de Nodos 2 cumple la k-anonimidad y estos ser´ıan las generalizaciones candidatas. 52 CAP´ ITULO 6. DISE˜ NO id dim 0 index 0 1 fnac 0 2 fnac 1 3 fnac 2 Tabla 6.6: Instancia de Nodos 1 id dim 0 index 0 dim 1 index 1 1 fnac 2 cod postal 0 2 fnac 2 cod postal 1 3 fnac 2 cod postal 2 Tabla 6.7: Instancia de Nodos 2 start end 1 2 2 3 Tabla 6.8: Instancia de Enlaces 1 start end 1 2 2 3 Tabla 6.9: Instancia de Enlaces 2 6.3. Diagrama de paquetes En este diagrama se definen los distintos paquetes a nivel l´ogico, es decir las clases e interfaces que forman parte de la aplicaci´on y la dependencia entre ellos. Adem´as de las librer´ıas que se importar´an y utilizar´an para el desarrollo de la aplicaci´on [8]. Figura 6.4: Diagrama de paquetes Las vistas de las que se compone la aplicaci´on son las siguientes: TableWindow: La vista principal, donde se mostrar´an los datos iniciales sin anonimizar y los distintos men´us para indicar los par´ametros necesarios para anonimizar estos datos. ImportDialog: El di´alogo mediante el cual se indican el fichero de datos que se quiere anonimizar y los par´ametros necesarios para importar estos datos a una base de datos relacional (el separador de los datos y los tipos y tama˜nos de los atributos que los componen). 53 CAP´ ITULO 6. DISE˜ NO HierarchyDialog: El di´alogo en el cual se indica las jerarqu´ıas de generalizaci´on de los atributos cuasi-identificadores. ResultsWindow: La ventana de resultados, donde se mostrar´an las generalizaciones candidatas para los cuasi-identificadores y valor de k escogidos. Tambi´en se podr´a aplicar la generalizaci´on deseada a los datos y se podr´an exportar los datos anonimizados. La aplicaci´on dispone de cuatro controladores, uno asociado a cada una de las vistas y todos ellos en constante comunicaci´on con la base de datos. Para comunicarse con la base de datos disponemos de una clase con nombre ’BD’ la cual contiene todos los m´etodos necesarios para insertar, actualizar, borrar o consultar informaci´on de la base de datos. Tambi´en tenemos la case Node, la cual es esencial para la implementaci´on del algoritmo Inc´ognito. Cada instancia de esta clase representa cada uno de los nodos del ´arbol de generalizaciones candidatas del algoritmo. Contiene todos los atributos necesarios para la implementaci´on del algoritmo (el valor de la generalizaci´on que representa, su conjunto de frecuencias, referencias a sus nodos padres...). Por ´ultimo, se utilizar´an las siguientes librer´ıas: subprocess: Esta librer´ıa permite ejecutar nuevos programas o procesos y obtener sus c´odigos de retorno. En este caso se utilizar´a para la ejecuci´on del bash script para importar los datos desde un fichero a la base de datos de mysql [30]. pymysql: Este paquete permite conectar la aplicaci´on con la base de datos y ejecutar sentencias mysql desde c´odigo Python [25]. PyQt: Esta librer´ıa es un conjunto de enlaces de Python para el marco de aplicaci´on Qt. Qt es un conjunto de bibliotecas y herramientas de desarrollo C++ para la implementaci´on de interfaces gr´aficas de usuario. Ser´a la librer´ıa utilizada para realizar la interfaz de la aplicaci´on [27]. csv: El m´odulo csv implementa clases para leer y escribir datos tabulares en formato CSV. Se utilizar´a para escribir y leer todos los ficheros de configuraci´on necesarios [6]. re: Este m´odulo proporciona operaciones de coincidencia de expresiones regulares [28]. itertools: Este m´odulo de python implementa distintas herramientas de iteradores, como por ejemplo un acumulador, una permutaci´on, una combinaci´on... En este caso se utiliza para la propuesta de atributos cuasi-identificadores explicada posteriormente, para la cual se necesita calcular todas las combinaciones posibles de varios n´umeros [16]. 54 CAP´ ITULO 6. DISE˜ NO 6.4. Diagrama de secuencia Para entender m´as f´acilmente los pasos realizados en el proceso de anonimizaci´on se incluye a continuaci´on un diagrama de secuencia. Figura 6.5: Diagrama de secuencia Anonimizar La clase Table es el controlador de la vista principal ’TableWindow’. El proceso de anonimizaci´on comienza cuando se acciona esta orden en la vista principal. El controlador recoge de su vista todos los datos necesarios para la anonimizaci´on, es decir, los cuasi-identificadores y el valor de k, y realiza el algoritmo de inc´ognito, en el cual se recorre un bucle tantas veces como atributos cuasiidentificadores haya. En cada iteraci´on del bucle se comprueba los niveles de generalizaci´on que tiene el atributo correspondiente y se crea una tabla nodos con las posibles generalizaciones y una tabla con los enlaces que unen estos nodos. Se comprueban los nodos que cumplen con la propiedad de k-anonimato y se marcan como posibles generalizaciones candidatas. Cuando el algoritmo ha terminado se muestran las posibles generalizaciones candidatas en la vista ’ResultsWindow’, cuyo controlador ’Results’ queda a la espera de que el usuario indique la generalizaci´on que quiere aplicar a los datos. Cuando este lo hace, se aplica la generalizaci´on correspondiente seg´un las jerarqu´ıas de cada atributo y se muestran los datos anonimizados. 55 CAP´ ITULO 6. DISE˜ NO 6.5. Diagrama de despliegue En la figura 6.6 se muestra el diagrama de despliegue del sistema. Este muestra la disposici´on de las particiones f´ısicas del sistema de informaci´on y la asignaci´on de los componentes software a estas particiones. Es decir, las relaciones f´ısicas entre los componentes software y hardware [5]. Figura 6.6: Diagrama de despliegue Todo el software necesario est´a desplegado en el mismo dispositivo, que en este caso es un PC. Dentro de este, existen dos nodos los cuales estar´an en continuo contacto para el correcto funcionamiento de la aplicaci´on. Base de datos: ser´a un servidor mysql instalado en la misma m´aquina en la que se ejecute la aplicaci´on. En este se guardar´an los datos especificados en el apartado anterior. [6.2] Aplicaci´on: la propia aplicaci´on, la cual estar´a compuesta por el c´odigo fuente de la misma, un archivo ’.csv’ o ’.txt’ el cual contendr´a los datos a anonimizar y un fichero denominado ’import.sh’ que ser´a necesario para importar los datos a la base de datos. Los datos para conectarse a la base de datos se guardan en el archivo ’DBConnection.txt’. Este ser´a necesario tanto para importar los datos, como para conectarse a estos desde la aplicaci´on. 56 CAP´ ITULO 6. DISE˜ NO 6.6. Patrones Los patrones de dise˜no son soluciones habituales a problemas comunes en el dise˜no de software. En nuestro caso, al disponer de una interfaz y una base de datos, el patr´on que m´as encaja con el proyecto es el patr´on Modelo-Vista-Controlador. 6.6.1. MVC Este patr´on expresa como organizar y estructurar los componentes de la aplicaci´on, sus responsabilidades y las relaciones existentes entre cada uno de ellos. La aplicaci´on se divide en tres capas o grupos de componentes, el modelo, en el que se indica una representaci´on de los datos del dominio, es decir, se crean entidades que nos servir´an para almacenar la informaci´on necesaria. La siguiente capa que describe este patr´on es la capa de la vista que es la responsable de generar la interfaz de la aplicaci´on, es aquella que interacciona directamente con el usuario. Por ´ultimo, el controlador, es el intermediario entre el modelo y la vista. Es el que se encarga de interpretar las acciones del usuario sobre la vista, realizar los cambios correspondientes en el modelo, y adaptar la vista en correlaci´on a esto. Por tanto, el controlador se podr´ıa definir como un coordinador general del sistema. El patr´on tambi´en define las relaciones existentes entre los tres componentes del MVC y con el usuario. Como se muestra en la figura 6.7, las acciones realizadas por el usuario las recoger´a y procesar´a el controlador, el cual ser´a tambi´en el responsable de modificar tanto la vista como el modelo. Por otra parte, el modelo ´unicamente informar´a sobre sus datos al controlador. Y por ´ultimo, la vista ser´an los datos mostrados al usuario [1]. Figura 6.7: Relaciones en el MVC Hay ciertas interacciones que el patr´on MVC en s´ı no indica como se realizan, por ello, este tiene diferentes versiones o diferentes patrones que indican como se gestiona por ejemplo las consultas a la base de datos, como est´a organizado el modelo en relaci´on con la base de datos, si tenemos un solo controlador para toda la aplicaci´on o si vamos a disponer de varios... Para explicar como se van a realizar todas estas acciones se definen los siguientes patrones [12]: 57 CAP´ ITULO 7. IMPLEMENTACI´ ON Elemento N´umero de tuplas Edad 91 Sexo 2 Raza 5 Edad, Sexo 182 Edad, Raza 449 Sexo, Raza 10 Edad, Sexo, Raza 881 Tabla 7.1: Elementos del Power Set frente al n´umero de tuplas distintas de cada elemento del PS ser´ıan los mostrados en la tabla 7.2. En este caso aunque el elemento con un m´aximo n´umero de tuplas distintas es el elemento (C´odigo postal, Sexo, Raza), la diferencia entre los los valores de los elementos, (C´odigo postal), (C´odigo postal, Sexo), (C´odigo postal, raza) y (C´odigo postal, Sexo, Raza) es m´ınima. Por lo tanto, el elemento escogido para formar el conjunto de atributos cuasi-identificadores ser´ıa el que contenga un menor n´umero de atributos, esto es, el elemento (C´odigo postal). Elemento N´umero de tuplas C´odigo postal 21648 Sexo 2 Raza 5 C´odigo postal, Sexo 22019 C´odigo postal, Raza 21942 Sexo, Raza 10 C´odigo postal, Sexo, Raza 22188 Tabla 7.2: Elementos del Power Set acompa˜nados del n´umero de tuplas distintas 7.6. Propuesta de jerarqu´ıa de generalizaci´on Las jerarqu´ıas de generalizaci´on de los atributos enteros suelen ser en forma de rango, es decir, en cada nivel se sustituye un d´ıgito del n´umero a procesar por un asterisco. Tal y como se muestra en la figura 7.3. Por esto y para ofrecer una mayor comodidad al usuario, se da la posibilidad de generar de manera autom´atica una jerarqu´ıa de este tipo. level 0 level 1 level 2 1986 198* 19** 1996 199* 19** Tabla 7.3: Ejemplo de jerarqu´ıa para n´umeros enteros 64 Cap´ıtulo 8 Validaci´on Para validar el algoritmo implementado se han hecho varias pruebas con distintos conjuntos de datos y se han contrastado nuestros resultados con los obtenidos a partir de la herramienta ARX, explicada en el cap´ıtulo 4 y la cual ha sido validada por la AEPD. 8.1. Prueba 1 En la primera prueba se utiliz´o un conjunto de datos peque˜no y sencillo. El conjunto de datos es el mostrado en la figura 8.1. Figura 8.1: Conjunto de datos de la prueba 1 Marcamos el atributo ”dolencia” como atributo sensible, y ”fnac” y ”cod postal” como cuasiidentificadores con las siguientes jerarqu´ıas: Figura 8.2: Jerarqu´ıa de generalizaci´on de cod postal para la prueba 1 Figura 8.3: Jerarquia de generalizaci´on de fnac para la prueba 1 Indicamos un valor de K igual a dos y generamos las generalizaciones candidatas desde ambas herramientas. La soluci´on obtenida por ARX se muestra en la figura 8.4. La soluci´on obtenida por 65 CAP´ ITULO 8. VALIDACI ´ ON nuestra aplicaci´on se muestra en la figura 8.5. Como se puede observar, ambas herramientas generan los mismos resultados. La ´unica diferencia es que ARX solo da una opci´on como generalizaci´on ´optima mientras que nuestra aplicaci´on da todas las opciones ´optimas. Figura 8.4: Generalizaciones candidatas dadas por ARX para la prueba 1 Figura 8.5: Generalizaciones candidatas dadas por la herramienta de este proyecto para la prueba 1 8.2. Prueba 2 Para la segunda prueba se utilizar´a unos datos m´as complejos, con jerarqu´ıas de generalizaci´on de m´as niveles. Los datos de entrada se muestran en la figura 8.6. Figura 8.6: Conjunto de datos de la prueba 2 Indicamos el atributo ”ingresos” como atributo sensible, y el resto como cuasi-identificadores. Las jerarqu´ıas de generalizaci´on de los cuasi-identificadores se muestran en las figuras 8.7, 8.8 y 8.9: 66 CAP´ ITULO 8. VALIDACI ´ ON Figura 8.7: Jerarqu´ıa de generalizaci´on de residencia para la prueba 2 Figura 8.8: Jerarqu´ıa de generalizaci´on de sexo para la prueba 2 Figura 8.9: Jerarqu´ıa de generalizaci´on de campo para la prueba 2 Indicamos un valor de K igual a 3 y generamos las generalizaciones candidatas desde ambas herramientas. La soluci´on obtenida por ARX se muestra en la figura 8.10 y la obtenida por la aplicaci´on propia en la figura 8.11. Como se puede observar las generalizaciones candidatas obtenidas desde ambas herramientas son las mismas. Sin embargo ARX muestra una generalizaci´on ´optima distinta, ya que se utilizan t´ecnicas distintas para calcular esta. En el caso de ARX se utilizan ciertas f´ormulas para calcular la p´erdida de informaci´on y la probabilidad de reidentificaci´on, y a partir de esto se calcula la generalizaci´on ´optima. En el caso de la herramienta de este proyecto se considera la generalizaci´on ´optima aquella con unos niveles de generalizaci´on m´as bajos. Figura 8.10: Generalizaciones candidatas dadas por ARX para la prueba 2 Figura 8.11: Generalizaciones candidatas dadas por la herramienta de este proyecto para la prueba 2 67 CAP´ ITULO 8. VALIDACI ´ ON 8.3. Prueba 3 Para la ´ultima prueba, se utiliz´o un conjunto de datos sencillo pero con una cantidad de datos elevada. El conjunto de datos ocupa 5 KB de memoria, y se gener´o aleatoriamente. Este se muestra en la figura 8.12. Figura 8.12: Conjunto de datos de la prueba 3 Se marcan como atributos cuasi-identificadores ”fnac”, ”sexo” y ”cod postal”, y ”docencia” como atributo sensible. Las jerarqu´ıas de generalizaci´on se muestran en las figuras 8.13, 8.14 y 8.15: Como la cantidad de datos es muy grande, se marca un valor de K bastante alto, en este caso se marca K=200. Generamos las generalizaciones candidatas desde ambas herramientas y obtenemos las siguientes soluciones. ARX muestra ´unicamente 6 generalizaciones candidatas, como se puede ver en la figura 8.16. Sin embargo hay muchas m´as generalizaciones entre medias de estas que no se muestran. En el conjunto de candidatos de nuestra herramienta se muestran las mismas generalizaciones que indica ARX, e incluye tambi´en las intermedias que son generalizaci´on directa de otras generalizaciones que si cumplen la k-anonimidad. Las generalizaciones candidatas dadas por nuestra herramienta se muestran en la figura 8.17. En este caso, la generalizaci´on ´optima coincide en ambos casos. 68 CAP´ ITULO 8. VALIDACI ´ ON Figura 8.13: Jerarqu´ıa de generalizaci´on de sexo para la prueba 3 Figura 8.14: Jerarqu´ıa de generalizaci´on de fnac para la prueba 3 Figura 8.15: Jerarqu´ıa de generalizaci´on de cod postal para la prueba 3 Figura 8.16: Generalizaciones candidatas dadas por ARX para la prueba 3 Figura 8.17: Generalizaciones candidatas dadas por la herramienta de este proyecto para la prueba 3 69 CAP´ ITULO 8. VALIDACI ´ ON 70 Cap´ıtulo 9 Conclusiones y trabajo futuro 9.1. Conclusiones Los principales objetivos marcados inicialmente se han cumplido. Se ha realizado una investigaci´on profunda sobre anonimizaci´on y m´as en concreto sobre K-anonimizaci´on, llegando a comprender totalmente esta t´ecnica. Se aprendieron los m´etodos de generalizaci´on y de supresi´on utilizados para anonimizar los datos y se descubri´o que el m´etodo de supresi´on pr´acticamente no se utiliza en la actualidad, ya que la p´erdida total de algunos datos no suele ser de utilidad. Por otro lado tambi´en se cumplieron algunos de los objetivos secundarios, como la generaci´on de una propuesta de atributos cuasi-identificadores y tambi´en la propuesta de una jerarqu´ıa de generalizaci´on para atributos num´ericos. Sin embargo, no se lleg´o a implementar la propuesta del valor de K ´optimo, ya que para esto eran necesarias variables estad´ısticas complejas, con las cuales hab´ıa que encontrar un valor de K que maximizara la privacidad, minimizando a su vez la p´erdida de informaci´on, lo cual se escapaba del alcance de este trabajo. No se utilizaron datos reales para las pruebas para evitar cuestiones adicionales como la declaraci´on del tratamiento de datos personales para que se incluyera en el Registro de Actividades de Tratamiento de Datos Personales (RAT) de la UVa [9]. No obstante, la aplicaci´on se dise˜no siguiendo requisitos de seguridad para poder ser usada con datos reales. Por ejemplo, se evit´o almacenar los datos de entrada, lo cual minimiza el riesgo de fuga de informaci´on y brechas de seguridad, esto es, minimizando los riesgos de privacidad. La realizaci´on de una aplicaci´on que implemente el algoritmo Inc´ognito sobre bases de datos relacionales sirvi´o para asentar los conocimientos adquiridos en la investigaci´on previa ya que se pusieron todos estos en pr´actica. Tambi´en ayud´o a comprender correctamente algunos conceptos que inicialmente se entendieron de manera err´onea. Adem´as, se aprendi´o a utilizar tecnolog´ıas nuevas que no se hab´ıan usado anteriormente, como la librer´ıa PyQT, la cual fue un gran descubrimiento, pues es una librer´ıa muy intuitiva y f´acil de usar. Por ´ultimo, se pudo mejorar la destreza del lenguaje de programaci´on Python con el cual se hab´ıa trabajado muy poco. La planificaci´on se cumpli´o durante las primeras semanas, sin embargo, la fase de implementaci´on llev´o m´as tiempo de lo pensado inicialmente. Adem´as durante esta fase hubo que modificar algunos 71 CAP´ ITULO 9. CONCLUSIONES Y TRABAJO FUTURO aspectos de las fases de an´alisis y dise˜no. La fase de pruebas sin embargo se llev´o a cabo en menos tiempo del planificado. 9.2. Trabajo futuro Se pueden realizar mejoras y avances sobre la aplicaci´on realizada. Una de estas es la propuesta del valor de K ´optimo calculando la p´erdida de informaci´on y el nivel de privacidad que se tiene con cada posible valor, escogiendo aquel que maximice la privacidad y minimice la p´erdida de informaci´on. Ya que la aplicaci´on procesa datos privados no anonimizados, ser´ıa conveniente avanzar con unos requisitos de privacidad m´as exigentes si se trata con datos reales, como es asegurarse que los datos del usuario se borran realmente al terminar el procedimiento de anonimizaci´on. Actualmente se borran todos los datos de la base de datos pero no se comprueba que est´an borrados de disco y de memoria. Para esto se deber´ıa realizar una operaci´on at´omica reescribiendo sobre los mismos bloques donde se almacenaron los datos del usuario. Adem´as, el proceso deber´ıa estar securizado. Una posible soluci´on es que las m´aquinas donde se ejecuta est´en situadas en entornos de ejecuci´on seguros para prevenir posibles ataques. Por ´ultimo, como se trata con datos personales, este tratamiento deber´ıa registrarse en el Registro de Actividades de Tratamiento de Datos Personales previsto en el art´ıculo 30 del Reglamento General de Protecci´on de Datos (RGPD) [11]. 72 Bibliograf´ıa [1] Jos´e Mar´ıa Aguilar. ((¿Qu´e es el patr´on MVC en programaci´on y por qu´e es ´uti?)) En: Campus MVP (2019). url:https://www.campusmvp.es/recursos/post/que-es-el-patron-mvcen-programacion-y-por-que-es-util.aspx. [2] Amnesia Anonymization Tool.url:https://amnesia.openaire.eu/. [3] ARX - Data Anonymization Tool.url:https://arx.deidentifier.org/. [4] BOE. ((Ley Org´anica 3/2018, de 5 de diciembre, de Protecci´on de Datos Personales y garant´ıa de los derechos digitales)). En: (2018). url:https://www.boe.es/boe/dias/2018/12/06/ pdfs/BOE-A-2018-16673.pdf. [5] Manuel Cillero. ((Diagrama de Despliegue)). En: manuel.cillero.es (). url:https://manuel. cillero.es/doc/metodologia/metrica-3/tecnicas/diagrama-de-despliegue/. [6] csv — Lectura y escritura de archivos CSV. 3.9.6. Python. url:https://docs.python.org/ es/3/library/csv.html. [7] Jenny Dearborn. ((La importancia de los datos: claves para su an´alisis)). En: Conecta software (2020). url:https://conectasoftware.com/libros/area/marketing-y-ventas/laimportancia-de-los-datos/. [8] ((Diagrama de paquetes)). En: DiagramasUML (). url:https://diagramasuml.com/paquetes/. [9] David Sanz Esteban. Registro de actividades de tratamiento. Universidad de Valladolid. 2021. url:https : / / secretariageneral . uva . es / competencias / proteccion - de - datos / registro-actividades-tratamiento/. [10] etomas. ((El orden de los algoritmos. . . esa gran O)). En: Plain Concepts (2012). url:https: //geeks.ms/etomas/2012/11/28/el-orden-de-los-algoritmos-esa-gran-o/. [11] Uni´on Europea. ((Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016 relativo a la protecci´on de las personas f´ısicas en lo que respecta al tratamiento de datos personales y a la libre circulaci´on de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento General de Protecci´on de Datos))). En: (2016). url:https://eurlex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32016R0679. [12] Martin Fowler. ((Catalog of Patterns of Enterprise Application Architecture)). En: (January 2003). url:https://martinfowler.com/eaaCatalog/. [13] GitHub: Where the world builds software.url:https://github.com. [14] M. Mercedes Mart´ınez Gonz´alez. ((Introducci´on pr´actica a la K-anonimizaci´on)). En: Diario La Ley n.º2 (2019). [15] ((IEEE Standard Glossary of Software Engineering Terminology)). En: IEEE Std 610.12-1990 (1990), p´ags. 1-84. doi:10.1109/IEEESTD.1990.101064. 73 CAP´ ITULO 10. ANEXO: GU´ IA DE USUARIO 10.4. Selecci´on del valor de ’K’ Por ´ultimo cuando tengamos todos los datos necesarios para aplicar el algoritmo de k-anonimizaci´on. Indicamos el valor de k que queremos que cumpla la anonimizaci´on y pulsamos el bot´on de anonimizar, el cual nos abrir´a una ventana nueva como la que se muestra en la figura 10.7. 10.5. Anonimizaci´on En la vista de resultados se muestran en la parte superior las generalizaciones candidatas que cumplen en valor de K indicado. Se muestran en rojo las generalizaciones ´optimas. Y en la parte inferior se muestran los datos sin los atributos identificadores. Para aplicar una generalizaci´on se selecciona la generalizaci´on deseada y se pulsa el bot´on ’Aplicar generalizaci´on’, el cual modifica los datos de la tabla inferior con la generalizaci´on indicada. 10.6. Exportaci´on de resultados Por ´ultimo, una vez que hemos aplicado la generalizaci´on deseada podemos exportar los datos anonimizados a un fichero .csv o .txt, con la opci´on del bot´on inferior de la aplicaci´on. 80 Cap´ıtulo 11 Anexo: Manual de instalaci´on Para instalar la aplicaci´on se requiere contar con: Base de datos MySQL o MariaDB Python Se deben instalar los siguientes paquetes: Qt5:sudo apt install qt5-default PyQt5:pip install PyQt5 PyMySQL:pip install PyMySQL Es necesario tener una base de datos en el servidor MySQL o MariaDB. Se recomienda tambi´en crear un usuario espec´ıfico para la aplicaci´on que ´unicamente tenga acceso a esta base de datos. Para ello accedemos al servidor con el usuario ’root’ y realizamos los siguientes pasos: 1. Creamos un usuario: CREATE USER ’user’@’localhost’ IDENTIFIED BY ’password’; 2. Creamos la base de datos: CREATE DATABASE ’database’; 3. Otorgamos al usuario todos los privilegios hacia esa base de datos: GRANT ALL PRIVILEGES ON ’database’.* TO ’user’@’localhost’; Por ´ultimo modificamos el fichero DBconnection.txt con los datos correspondientes para conectarse a la base de datos que acabamos de crear. Este fichero contiene el siguiente formato: host=’localhost’ user=’annon’ passwd=’password’ database=’TFG’ Para iniciar la aplicaci´on s´olamente habr´a que ejecutar el archivo start.sh. 81 CAP´ ITULO 11. ANEXO: MANUAL DE INSTALACI´ ON 82 Cap´ıtulo 12 Anexo: RGPD 12.1. Considerando 26 Los principios de la protecci´on de datos deben aplicarse a toda la informaci´on relativa a una persona f´ısica identificada o identificable. Los datos personales seudonimizados, que cabr´ıa atribuir a una persona f´ısica mediante la utilizaci´on de informaci´on adicional, deben considerarse informaci´on sobre una persona f´ısica identificable. Para determinar si una persona f´ısica es identificable, deben tenerse en cuenta todos los medios, como la singularizaci´on, que razonablemente pueda utilizar el responsable del tratamiento o cualquier otra persona para identificar directa o indirectamente a la persona f´ısica. Para determinar si existe una probabilidad razonable de que se utilicen medios para identificar a una persona f´ısica, deben tenerse en cuenta todos los factores objetivos, como los costes y el tiempo necesarios para la identificaci´on, teniendo en cuenta tanto la tecnolog´ıa disponible en el momento del tratamiento como los avances tecnol´ogicos. Por lo tanto los principios de protecci´on de datos no deben aplicarse a la informaci´on an´onima, es decir informaci´on que no guarda relaci´on con una persona f´ısica identificada o identificable, ni a los datos convertidos en an´onimos de forma que el interesado no sea identificable, o deje de serlo. En consecuencia, el presente Reglamento no afecta al tratamiento de dicha informaci´on an´onima, inclusive con fines estad´ısticos o de investigaci´on. 12.2. Art´ıculo 25: Protecci´on de datos desde el dise˜no y por defecto 1. Teniendo en cuenta el estado de la t´ecnica, el coste de la aplicaci´on y la naturaleza, ´ambito, contexto y fines del tratamiento, as´ı como los riesgos de diversa probabilidad y gravedad que entra˜na el tratamiento para los derechos y libertades de las personas f´ısicas, el responsable del tratamiento aplicar´a, tanto en el momento de determinar los medios de tratamiento como en el momento del propio tratamiento, medidas t´ecnicas y organizativas apropiadas, como la seudonimizaci´on, concebidas para aplicar de forma efectiva los principios de protecci´on de datos, como la minimizaci´on de datos, e integrar las garant´ıas necesarias en el tratamiento, a fin de cumplir los requisitos del presente Reglamento y proteger los derechos de los interesados. 2. El responsable del tratamiento aplicar´a las medidas t´ecnicas y organizativas apropiadas con miras a garantizar que, por defecto, solo sean objeto de tratamiento los datos personales que sean necesarios para cada uno de los fines espec´ıficos del tratamiento. Esta obligaci´on se aplicar´a a la 83 CAP´ ITULO 12. ANEXO: RGPD cantidad de datos personales recogidos, a la extensi´on de su tratamiento, a su plazo de conservaci´on y a su accesibilidad. Tales medidas garantizar´an en particular que, por defecto, los datos personales no sean accesibles, sin la intervenci´on de la persona, a un n´umero indeterminado de personas f´ısicas. 3. Podr´a utilizarse un mecanismo de certificaci´on aprobado con arreglo al art´ıculo 42 como elemento que acredite el cumplimiento de las obligaciones establecidas en los apartados 1 y 2 del presente art´ıculo. 84