Integración de políticas de privacidad de aplicaciones web

Universidad de Valladolid Escuela de Ingenier´ıa Inform´atica TRABAJO FIN DE GRADO Grado en Ingenier´ıa Inform´atica Menci´on Tecnolog´ıas de la Informaci´on Integraci´on de pol´ıticas de privacidad de aplicaciones web Autor: D. Javier Miguel Tejero ´ Alvarez Tutores: D˜na. Mercedes Mart´ınez Gonz´alez D. Amador Aparicio de la Fuente 2 Resumen El objetivo de este proyecto consiste en obtener informaci´on estructurada de distintas fuentes de datos heterog´eneas sobre pol´ıticas de privacidad y ofrecer un acceso unificado a los usuarios para su consulta. Para ello se construye un almac´en de datos, un Warehouse, describiendo todo el proceso para su elaboraci´on, desde la obtenci´on de datos hasta su implementaci´on final donde se facilitar´a a los usuarios su posterior consulta a trav´es de una aplicaci´on web. 3 4 ´ Indice general 1. Introducci´on 11 1.1. Motivaci´on........................................ 11 1.2. Objetivos ........................................ 12 1.3. Entorno ......................................... 13 1.4. Estructuradelamemoria ............................... 13 2. Planificaci´on 15 2.1. Planificaci´oninicial................................... 15 2.2. An´alisisderiesgos.................................... 15 2.3. Planificaci´onfinal.................................... 20 3. Fuentes de datos 21 3.1. Estructura........................................ 21 3.2. PrivaSeer ........................................ 22 3.2.1. Abstracci´on ................................... 23 3.2.2. Formato de archivo y disponibilidad de los datos . . . . . . . . . . . . . . . 25 3.2.3. Completitud de la fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3. Terms of Service; Didn’t Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.1. Abstracci´on ................................... 27 3.3.2. Formato de archivo y disponibilidad de los datos . . . . . . . . . . . . . . . 28 3.3.3. Completitud de la fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4. OPP-115Manual .................................... 29 3.4.1. Abstracci´on ................................... 30 3.4.2. Formato de archivo y disponibilidad de los datos . . . . . . . . . . . . . . . 34 3.4.3. Completitud de la fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.5. OPP-115Autom´atica.................................. 35 3.5.1. Abstracci´on ................................... 35 6´ INDICE GENERAL 3.5.2. Formato de archivo y disponibilidad de los datos . . . . . . . . . . . . . . . 36 3.5.3. Completitud de la fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.6. Valoraci´on general y comparativa entre fuentes . . . . . . . . . . . . . . . . . . . . 37 4. Tecnolog´ıas utilizadas 41 4.1. Warehouse........................................ 41 4.2. ETL: Extract, Transform and Load . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.1. Comunicaci´on con las fuentes de datos: Interoperabilidad . . . . . . . . . . 43 4.2.2. Extracci´on.................................... 44 4.2.3. Transformaci´on ................................. 44 4.2.4. Carga ...................................... 45 4.2.5. Riesgos de un Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3. SQL Server Integration Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4. SQL Server Management Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.5. Webscraping ...................................... 49 4.6. Tecnolog´ıasweb..................................... 52 4.6.1. Tecnolog´ıas en la parte del cliente . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.2. Tecnolog´ıas en la parte del servidor . . . . . . . . . . . . . . . . . . . . . . 52 5. An´alisis 53 5.1. Tiposdeconsultas ................................... 53 5.2. An´alisis de la construcci´on del Warehouse . . . . . . . . . . . . . . . . . . . . . . 54 5.2.1. Requisitos.................................... 54 5.3. An´alisis de la aplicaci´on de consulta . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3.1. Requisitos.................................... 56 5.3.2. Casosdeuso .................................. 57 5.3.3. Modelo de dominio inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6. Dise˜no 61 6.1. Dise˜no de la construcci´on del Warehouse . . . . . . . . . . . . . . . . . . . . . . . 61 6.1.1. Arquitectura .................................. 61 6.1.2. Diagrama Entidad-Relaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.1.3. Dise˜nof´ısico................................... 64 6.2. Dise˜no de la aplicaci´on de consulta . . . . . . . . . . . . . . . . . . . . . . . . . . 66 ´ INDICE GENERAL 7 6.2.1. MVC....................................... 66 6.2.2. Arquitectural´ogica............................... 67 6.2.3. Diagrama de clases de dise˜no . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.2.4. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.2.5. Arquitecturaf´ısica ............................... 70 7. Implementaci´on 71 7.1. Implementaci´on de la construcci´on del Warehouse . . . . . . . . . . . . . . . . . . 71 7.1.1. Creaci´on de la estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.1.2. Usuariosypermisos .............................. 71 7.1.3. Proceso de carga de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.1.4. ProcesoETLToS;DR.............................. 74 7.1.5. Proceso ETL OPP-115 Manual . . . . . . . . . . . . . . . . . . . . . . . . 75 7.1.6. Proceso ETL PrivaSeer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.2. Implementaci´on de la aplicaci´on de consulta . . . . . . . . . . . . . . . . . . . . . 83 7.2.1. ClasesControlador ............................... 83 7.2.2. ClasesModelo.................................. 83 7.2.3. ClaseConexi´on ................................. 84 7.2.4. Vistas de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8. Pruebas 85 8.1. Pruebas de funcionamiento general . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.2. Pruebasdeseguridad.................................. 91 9. Conclusiones y trabajo futuro 93 Bibliograf´ıa 95 A. Pruebas para el proceso de carga 97 B. Copia de seguridad y actualizaci´on 101 B.1.Copiadeseguridad ...................................101 B.2.Actualizaci´on ......................................102 C. Manual de usuario 105 D. Documentaci´on adicional 109 8´ INDICE GENERAL ´ Indice de figuras 1.1. Esquema general de integraci´on de informaci´on. . . . . . . . . . . . . . . . . . . . 12 2.1. Planificaci´on inicial de tareas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2. Diagrama de Gantt de planificaci´on inicial temporal. . . . . . . . . . . . . . . . . 16 2.3. Planificaci´on final de tareas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4. Diagrama de Gantt de planificaci´on final temporal. . . . . . . . . . . . . . . . . . 20 4.1. ProcesoETL. ...................................... 43 4.2. Web scraping conParseHub............................... 51 4.3. Obtenci´on de los datos web scraping conParseHub.................. 51 5.1. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2. Modelo de dominio inicial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.1. Dise˜no de la arquitectura l´ogica del Warehouse. . . . . . . . . . . . . . . . . . . . 62 6.2. Diagrama Entidad-Relaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.3. Diagramarelacional. .................................. 63 6.4. Modelo Vista Controlador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.5. Arquitectura l´ogica aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.6. Modelo de dominio de dise˜no. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.7. Diagrama de secuencia b´usqueda de datos. . . . . . . . . . . . . . . . . . . . . . . 69 6.8. Arquitectura f´ısica aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.1. Creaci´on de usuario y permisos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.2. ETLToS;DRServicio. ................................. 74 7.3. ETL OPP-115 Manual Dato. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.4. ETL OPP-115 Manual Tercero. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.5. ETL OPP-115 Manual Tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9 16 CAP´ ITULO 2. PLANIFICACI ´ ON Figura 2.1: Planificaci´on inicial de tareas. Figura 2.2: Diagrama de Gantt de planificaci´on inicial temporal. 2.2. AN ´ ALISIS DE RIESGOS 17 Riesgo 01 Falta de experiencia en las tecnolog´ıas empleadas. Impacto Cr´ıtico. Probabilidad Media. Indicador Uso de tecnolog´ıas desconocidas y retraso temporal en la planificaci´on. Plan de protecci´on Formaci´on para aprender acerca de esa tecnolog´ıa empleada. Plan de contingencia Buscar ayuda externa para orientar el proyecto correctamente. Tabla 2.1: Riesgo 01: Falta de experiencia en las tecnolog´ıas empleadas. Riesgo 02 Enfermedad del alumno. Impacto Cr´ıtico. Probabilidad Baja. Indicador Ninguno, de dif´ıcil predicci´on. Plan de protecci´on Establecer una planificaci´on hitos e ir adelantado a la finalizaci´on de esos hitos. Plan de contingencia Replanificar tareas a realizar en funci´on del tiempo que no ha estado disponible, seg´un lo planificado. Tabla 2.2: Riesgo 02: Enfermedad del alumno. Riesgo 03 Modificaci´on del proyecto. Impacto Cr´ıtico. Probabilidad Media. Indicador Cambio en los requisitos iniciales del proyecto. Plan de protecci´on Reuniones tras la finalizaci´on de fases, entregas parciales de comprobaci´on. Plan de contingencia Identificar las partes afectadas para incorporar los nuevos cambios lo antes posible. Tabla 2.3: Riesgo 03: Modificaci´on del proyecto. 18 CAP´ ITULO 2. PLANIFICACI ´ ON Riesgo 04 P´erdida de informaci´on. Impacto Cr´ıtico. Probabilidad Media. Indicador Fallos en alg´un repositorio intermedio o final, sin datos disponibles. Plan de protecci´on Copias de seguridad. Realizarla lo m´as pr´oximo a cualquier p´erdida. Plan de contingencia Recuperaci´on de la informaci´on desde la ´ultima copia de seguridad ´util realizada. Tabla 2.4: Riesgo 04: P´erdida de informaci´on. Riesgo 05 Corrupci´on de la informaci´on. Impacto Cr´ıtico. Probabilidad Bajo. Indicador La informaci´on no se corresponde con la original. Plan de protecci´on Realizaci´on de copias de seguridad. Plan de contingencia Recuperaci´on de la informaci´on desde la ´ultima copia de seguridad ´util realizada. Tabla 2.5: Riesgo 05: Corrupci´on de la informaci´on. Riesgo 06 Equipo de trabajo estropeado. Impacto Cr´ıtico. Probabilidad Bajo. Indicador No se enciende, apagados y bloqueos espont´aneos. Plan de protecci´on Realizaci´on de copias de seguridad. Usar almacenamiento externo con replicaci´on. Plan de contingencia Recuperaci´on de la informaci´on desde la ´ultima copia de seguridad ´util realizada o dispositivo de almacenamiento. Tabla 2.6: Riesgo 06: Equipo de trabajo estropeado. 2.2. AN ´ ALISIS DE RIESGOS 19 Riesgo 07 Fuentes de datos no disponibles. Impacto Cr´ıtico. Probabilidad Bajo. Indicador Servidores ca´ıdos donde no se puede acceder a los datos para su descarga. Plan de protecci´on Copias de seguridad de los datos. Plan de contingencia Recuperaci´on de la informaci´on desde la ´ultima copia de seguridad ´util realizada. Tabla 2.7: Riesgo 07: Fuentes de datos no disponibles. Riesgo 08 Actualizaci´on Impacto Cr´ıtico. Probabilidad Media. Indicador Organizaciones con incorporaci´on de nuevos an´alisis de documentos de pol´ıticas. Plan de protecci´on Copias de ficheros y comparativa de los nuevos. Plan de contingencia Identificaci´on de los cambios e incorporarlos. Tabla 2.8: Riesgo 08: Actualizaci´on. Riesgo 09 Pruebas y validaci´on escasas. Impacto Cr´ıtico. Probabilidad Bajo. Indicador Consultas sin resultados o resultados err´oneos. Plan de protecci´on Establecimiento de consultas de entrada y los resultados esperados. Plan de contingencia Identificar y solucionar los problemas lo antes posible. Tabla 2.9: Riesgo 09: Pruebas y validaci´on escasas. 20 CAP´ ITULO 2. PLANIFICACI ´ ON 2.3. Planificaci´on final Una vez enumerados los riesgos a los que se ha sometido el proyecto y posibles retrasos que pod´ıamos tener a medida que se avanzaba, la nueva planificaci´on de tareas no ha variado mucho desde la planificaci´on inicial. La fecha de finalizaci´on del proyecto ha cambiado para aplicar las modificaciones. Si bien, cualquier retraso que se ha tenido principalmente en la parte inicial con el conocimiento de las fuentes de datos y obtenci´on de conocimientos del proyecto, se han visto compensados en las fases posteriores de an´alisis y dise˜no. El nuevo diagrama de Gantt con la planificaci´on de tareas finalmente ha sido el de las figuras 2.3 y 2.4. Figura 2.3: Planificaci´on final de tareas. Figura 2.4: Diagrama de Gantt de planificaci´on final temporal. Cap´ıtulo 3 Fuentes de datos Anteriormente ya hemos hablado de la importancia que tiene la privacidad en las personas. Cuando se utilizan distintos servicios, que necesitan nuestros datos y las comunicaciones se realizan a trav´es de ellos, es necesario tener un conocimiento acerca de ellos. Entre todos los servicios disponibles, nos centraremos en aquellos servicios de correo y mensajer´ıa. Hay organizaciones que se encargan de realizar an´alisis sobre la privacidad de los servicios. Las cuatro fuentes de datos con las que se van a trabajar tienen el mismo objetivo com´un, la simplificaci´on de la informaci´on presentada haci´endola m´as descriptiva y categorizada, pero con pr´acticas totalmente diferentes. 3.1. Estructura Antes de comenzar con la descripci´on y la obtenci´on de la informaci´on que est´a disponible en cada fuente de datos sobre pol´ıticas de privacidad, veremos c´omo est´a estructurado un documento de una pol´ıtica de privacidad [7]. Toda pol´ıtica de privacidad incluye los siguientes aspectos: Informaci´on del responsable del tratamiento o de su representante: Suministrar informaci´on del responsable del tratamiento de los datos o de su represente. Datos del responsable en materia de protecci´on de datos: Deben aparecer los datos de contacto del responsable del tratamiento de los datos personales. As´ı, se indicar´a el nombre o raz´on social y NIF, las direcciones electr´onicas y postales y el n´umero de tel´efono del responsable de tratamiento o su representante. Informaci´on sobre la finalidad del tratamiento: Se informar´a sobre la finalidad del tratamiento, es decir, para qu´e ser´an usados los datos personales que se recojan (por ejemplo, fines estad´ısticos o para el env´ıo de informaci´on). Tambi´en se debe especificar la legitimaci´on jur´ıdica con la que se han obtenido los datos. Es necesario contar con el consentimiento expreso de los usuarios para registrar y tratar sus datos personales. Terceros destinatarios de los datos personales: Informar a los usuarios de los terceros destinatarios a quienes se env´ıan los datos personales, si esta cesi´on de datos se produce, informando de qui´enes son esos encargados de tratamiento. Tambi´en es necesario informar de las cookies de terceros, puesto que estas registran datos personales de los usuarios. Es decir, identificar tambi´en a estos terceros destinatarios como 21 22 CAP´ ITULO 3. FUENTES DE DATOS otros encargados de tratamiento, que podr´an tener acceso a los datos personales del usuario, si este da su consentimiento para ello. Transferencias internacionales: Si se van a transferir datos fuera de pa´ıses de la Uni´on Europa, se tiene que informar de ello en la pol´ıtica de privacidad. Plazo de conservaci´on de los datos: Indicar el plazo m´aximo durante el que se conservar´an los datos personales facilitados por los usuarios. Derechos ARCO: Informaci´on referente a c´omo pueden ejercer los usuarios sus derechos ARCO (Acceso, Rectificaci´on, Cancelaci´on y Oposici´on) y a trav´es de que canal hacerlo. Explicaci´on sobre el uso de decisiones individuales automatizadas: Si se realizan decisiones en el tratamiento automatizado de datos, como son la elaboraci´on de perfiles de usuario, es necesario una explicaci´on de la l´ogica de su fundamento. Se explican los efectos y el alcance que el proceso automatizado tiene sobre ´el. 3.2. PrivaSeer PrivaSeer [1] es un corpus de casi un mill´on y medio de pol´ıticas de privacidad de sitios web, realizado a trav´es de una evaluaci´on autom´atica por aprendizaje de las tecnolog´ıas de seguimiento utilizadas, regulaciones y ´organos de regulaci´on que utilizan para velar por la aplicaci´on efectiva de su c´odigo. Para obtener todo este conjunto de corpus de pol´ıticas de privacidad de los distintos servicios, se llevan a cabo una canalizaci´on importante de pasos que se describen: Recopilaci´on los documentos. •Uso de Common Crawl: Proporcionar una instant´anea de la web al incluir los nuevos rastreos de dominios populares y nuevos. •Selecci´on de URL: El paradigma de la privacidad es el de “Aviso y elecci´on”. Hay una tendencia a usar palabras clave en las URL como pueden ser “Pol´ıtica de privacidad” y “Protecci´on de datos”. •Rastreo web: Rastreo de las URL seleccionadas mediante la utilizaci´on de programas como Scrapy, donde se eliminan aquellas que conducen a p´aginas de error, duplicados y sin respuesta. Filtrado de documentos. •Detecci´on de idioma: Identificaci´on del idioma de ingl´es frente a otros, usando el paquete de Python Langid y descartar aquellos documentos con un idioma distinto del ingl´es. 3.2. PRIVASEER 23 •Clasificaci´on de documentos: Se realiza un etiquetado manual para establecer un hi- to del trabajo realizado para posteriormente realizar un aprendizaje autom´atico no supervisado usando distintos algoritmos. Tambi´en se hace uso de un aprendizaje autom´atico supervisado usando las caracter´ısticas extra´ıdas de la URL, otro de la p´agina web y otro usando caracter´ısticas de ambos. •Verificaci´on cruzada de URL: Comparaci´on de las URL obtenidas hasta el momento, con las que est´an disponibles en la p´agina de inicio, normalmente en el pie de p´agina de su sitio web para cada organizaci´on. •Extracci´on de contenido: Eliminaci´on del contenido est´andar en todas las pol´ıticas de privacidad dejando ´unicamente el texto de la pol´ıtica de privacidad. •Detecci´on de duplicados y casi duplicados: Eliminaci´on de los elementos duplicados exactos aplicando un hash a todos los documentos sin procesar y descartando las copias de hash exactas. Entradas similares producen valores hash similares, por lo que calculando la distancia entre los valores obtenidos dentro de un mismo dominio se pueden localizar estos elementos casi duplicados. An´alisis de Corpus. •Legibilidad: Muy importante para la toma de decisiones de lectura o ignoraci´on del documento de la pol´ıtica de privacidad por parte de los usuarios. •Modelado de temas: Usando un aprendizaje autom´atico no supervisado, que extrae la distribuci´on m´as probable de palabras en temas, a trav´es de un proceso iterativo. Identificar diferentes categor´ıas de an´alisis de datos en las pol´ıticas de privacidad y la extracci´on de temas comunes para los p´arrafos. •Extracci´on de frases clave: Las palabras clave y frases clave se prestan bien para resumir el contenido de una pol´ıtica de privacidad. •Similitud de las pol´ıticas de privacidad web: Algunas pol´ıticas de privacidad ten´ıan exactamente la misma redacci´on en varias secciones, y solo se diferenciaban por el nombre de la organizaci´on, siendo pr´acticamente similares. Como resultado, tenemos el corpus a trav´es de una interfaz de usuario y accesible por cualquier persona, usando un motor de b´usqueda para el descubrimiento. 3.2.1. Abstracci´on En PrivaSeer, como en cualquier otra fuente, toda la informaci´on que se presenta al usuario a trav´es de su interfaz tiene que ser alojada en alg´un almac´en f´ısico. Algunas fuentes s´ı que proporcionan alg´un mecanismo para que sea accesible por cualquier persona a esta informaci´on 24 CAP´ ITULO 3. FUENTES DE DATOS ya sea bien a trav´es de su API o descargables con los datos. Al realizar la abstracci´on, estar´ıamos determinando c´omo estar´ıan alojados estos datos como si fuese una base de datos relacional. El esquema relacional resultante ser´ıa: SERVICIO(nombre servicio, fuente, fecha version) nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad que se describe. Formato del dato: Texto. fuente: Enlace al documento actual de la pol´ıtica de privacidad del servicio analizado. No se corresponde con el documento realmente analizado. Formato del dato: Texto. fecha version: Fecha relativa a la versi´on del documento de privacidad en la cual se ha realizado el an´alisis para la incorporaci´on en la fuente de datos. Puede diferir del que hay actualmente en la fuente. Formato del dato: Fecha. INDUSTRIA(nombre servicio, nombre industria, subnombre industria) nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad que se describe. Formato del dato: Texto. nombre industria: Actividad donde se desarrolla el servicio. Formato del dato: Texto. subnombre industria: Subactividad donde tiene desarrollo el servicio. Formato del dato: Texto. TRACKING(nombre servicio, categoria track) nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad que se describe. Formato del dato: Texto. categoria track: ´ Ambito de la tecnolog´ıa de seguimiento de la informaci´on por el servicio [terceros, cookies, registros, baliza web, huellas dactilares, cookies flash, identificaci´on del dispositivo, identificaci´on de publicidad]. Formato del dato: Texto. REGULACION(nombre servicio, regulador) nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad que se describe. Formato del dato: Texto. regulador: Valor de la regulaci´on y acuerdos del tratamiento y circulaci´on de la informaci´on [GDPR, COPPA, Privacy Shield, CalOPPA]. Formato del dato: Texto. ORGANO(nombre servicio, organo regulador) nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad que se describe. Formato del dato: Texto. 3.2. PRIVASEER 25 organo regulador: Valor del ´organo de supervisi´on y autorregulaci´on de la informaci´on [NAI, DAA, EDAA]. Formato del dato: Texto. 3.2.2. Formato de archivo y disponibilidad de los datos Todos los datos descritos en la abstracci´on se encuentran accesibles a trav´es de una interfaz web. Se extraen ficheros en formato de texto JSON (JavaScript Object Notation) tras realizar un web scraping con herramientas para extraer informaci´on de su sitio web donde est´an presente los datos. Para obtener una respuesta, es necesario realizar una b´usqueda en un cuadro de texto por el nombre del servicio o su URL, seleccion´andolo a trav´es de un bot´on de tipo radio. Una vez realizada la b´usqueda, podemos ordenar por coincidencia, por ranking, por legibilidad, por categor´ıas y por niveles. La fecha de incorporaci´on de los datos es del a˜no 2019 y la frecuencia de actualizaci´on de los datos presentes es baja. 3.2.3. Completitud de la fuente En cuanto al an´alisis realizado de pol´ıticas de privacidad tiene lugar en distintos sectores bien diferenciados, cuyas categor´ıas y subcategor´ıas est´an bien jerarquizadas y diferenciadas donde nos encontramos: Consumidor y cadena de suministro: Minorista, industria textil y moda, dise˜no, bienes de consumo, servicios al consumidor, transporte / cami´on / ferrocarril, al por mayor, instalaciones de servicios, muebles, material y equipo comercial, producci´on alimentaria, log´ıstica y cadena de suministro, servicios individuales y familiares, cosm´eticos, art´ıculos de lujo y joyer´ıa, artes y oficios, mar´ıtimo, envases y contenedores, textiles, agricultura, pl´asticos, comercio internacional y desarrollo, almacenamiento, entrega de paquetes / fletes, l´acteos, supermercados, pesca, tabaco y ganader´ıa. Tecnolog´ıa de la informaci´on y electr´onica: Servicios y tecnolog´ıa de la informaci´on, software de computadora, internet, telecomunicaciones, electr´onica de consumo, servicios de informaci´on, seguridad inform´atica y de redes, hardware de computadora, redes inform´aticas, semiconductores, inal´ambrico, desarrollo de programas y nanotecnolog´ıa. M´edico: Salud, bienestar y fitness, atenci´on sanitaria y hospitalaria, pr´actica m´edica, dispositivos m´edicos, productos farmac´euticos, biotecnolog´ıa, cuidado de la salud mental, veterinario, medicina alternativa. Deportes, medios y entretenimiento: Entretenimiento, servicios para eventos, deportes, producci´on de medios, imprenta, medios en l´ınea, m´usica, art´ıculos deportivos, relaciones p´ublicas y comunicaciones, medios de difusi´on, fotograf´ıa, dise˜no gr´afico, juegos de computadora, instalaciones y servicios recreativos, peri´odicos, artes esc´enicas, bellas artes, pel´ıculas y animaci´on. Civil, mec´anica y el´ectrica: Construcci´on, automotor, fabricaci´on el´ectrica / electr´onica, ingenier´ıa industrial o mec´anica, maquinaria, petr´oleo y energ´ıa, materiales de construcci´on, energ´ıa renovable y medio ambiente, arquitectura y planificaci´on, productos qu´ımicos, 32 CAP´ ITULO 3. FUENTES DE DATOS terceros: Cu´al es el tercero involucrado en la pr´actica de datos. Formato del dato: Texto. accion: Especifica si realmente la pol´ıtica hace o no hace algo expl´ıcitamente. Formato del dato: Texto. tipo coleccion: C´omo recopila, rastrea u obtiene el tercero la informaci´on del usuario. Formato del dato: Texto. anonimizacion: Indica si la pr´actica de informaci´on o datos est´a vinculada a la identidad del usuario o si es an´onima. Formato del dato: Texto. eleccion usuario: Indica si se ofrecen expl´ıcitamente opciones de usuario para esta pr´actica. Formato del dato: Texto. referencia texto: Texto resultante clasificado al que se hace referencia. Formato del dato: Texto. ELECCION(nombre servicio, tipo eleccion, alcance eleccion, tipo informacion, proposito, referencia texto) nombre servicio: Nombre ´unico del servicio que se describe. Formato del dato: Texto. tipo eleccion: Tipo de elecci´on del usuario u opciones de control de privacidad disponibles al usuario. Formato del dato: Texto. alcance eleccion: Alcance de la elecci´on o control del usuario de la recopilaci´on y uso en primera parte o en terceros. Formato del dato: Texto. tipo informacion: El tipo de informaci´on que aplica la elecci´on del usuario. Formato del dato: Texto. proposito: Objetivo que se aplica la elecci´on del usuario. Formato del dato: Texto. referencia texto: Texto resultante clasificado al que se hace referencia. Formato del dato: Texto. ACCESO(nombre servicio, derechos acceso, alcance acceso, referencia texto) nombre servicio: Nombre ´unico del servicio que se describe. Formato del dato: Texto. derechos acceso: Opciones que se ofrecen a los usuarios para acceder, editar y eliminar la informaci´on que la organizaci´on del servicio tiene sobre ellos. Formato del dato: Texto. alcance acceso: Si se ofrece el acceso a la informaci´on, a qu´e informaci´on se aplica. Formato del dato: Texto. referencia texto: Texto resultante clasificado al que se hace referencia. Formato del dato: Texto. RETENCION(nombre servicio, periodo retencion, proposito retencion, tipo informacion, referencia texto) 3.4. OPP-115 MANUAL 33 nombre servicio: Nombre ´unico del servicio que se describe. Formato del dato: Texto. periodo retencion: Cuanto tiempo se almacenan los datos. Formato del dato: Texto. proposito retencion: Prop´osito que se aplica a la pr´actica de retenci´on. Formato del dato: Texto. tipo informacion: El tipo de informaci´on para el que se especifica el periodo de retenci´on. Formato del dato: Texto. referencia texto: Texto resultante clasificado al que se hace referencia. Formato del dato: Texto. SEGURIDAD(nombre servicio, medida seguridad, referencia texto) nombre servicio: Nombre ´unico del servicio que se describe. Formato del dato: Texto. medida seguridad: El tipo de seguridad que implementa el servicio para proteger la informaci´on de los usuarios. Formato del dato: Texto. referencia texto: Texto resultante clasificado al que se hace referencia. Formato del dato: Texto. CAMBIO(nombre servicio, tipo notificacion, tipo cambio, opciones usuario, referencia texto) nombre servicio: Nombre ´unico del servicio que se describe. Formato del dato: Texto. tipo notificacion: C´omo se notifica al usuario cu´ando cambia la pol´ıtica de privacidad. Formato del dato: Texto. tipo cambio: Tipo de cambios en la pol´ıtica que se notifica a los usuarios. Formato del dato: Texto. opciones usuario: Opciones que se ofrecen al usuario cuando cambia la pol´ıtica. Formato del dato: Texto. referencia texto: Texto resultante clasificado al que se hace referencia. Formato del dato: Texto. AUDIENCIA(nombre servicio, grupo audiencia, referencia texto) nombre servicio: Nombre ´unico del servicio que se describe. Formato del dato: Texto. grupo audiencia: A que audiencia se refiere el segmento de la pol´ıtica. Formato del dato: Texto. referencia texto: Texto resultante clasificado al que se hace referencia. Formato del dato: Texto. 34 CAP´ ITULO 3. FUENTES DE DATOS 3.4.2. Formato de archivo y disponibilidad de los datos Los datos est´an presentes de dos formas. A trav´es de un repositorio descargable de ficheros en formato CSV (valores separados por comas), donde uno de sus campos incorpora notaci´on en formato de texto JSON (JavaScript Object Notation). La otra es a trav´es de una interfaz web de usuario en la cual se puede visualizar mejor las distintas categor´ıas de seguimiento y tratamiento de la informaci´on en las que se clasifica el texto de la pol´ıtica. Para obtener una respuesta es necesario realizar una b´usqueda del fichero CSV en el repositorio que vamos a analizar y posteriormente obtener la columna de ese archivo que contiene el formato JSON con los datos. La fecha de incorporaci´on de los datos es del a˜no 2015 y la frecuencia de actualizaci´on de los datos presentes es muy baja, casi nula. 3.4.3. Completitud de la fuente En cuanto al an´alisis realizado manualmente de las 115 pol´ıticas de privacidad, se obtiene el conjunto a trav´es de las Tendencias de Google (Google Trends) para obtener pol´ıticas de privacidad de un conjunto m´as diverso de sitios web [10]. Cada una de las tendencias se analiza de diferente forma para obtener los resultados. Tambi´en se realiza un muestreo por categor´ıas, donde se organiza el conjunto de datos de acuerdo con las categor´ıas principales de Alexa / DMOZ / ODP (listado y categorizaci´on de enlaces a p´aginas web) en Estados Unidos para obtener un conjunto de datos sobre el que hacer comparaciones relativas entre sitios web de la misma categor´ıa. En DMOZ / ODP la mayor´ıa de los sitios web ya est´an categorizados. Las categor´ıas donde que se utilizan ser´ıan: Servicios de letras. Servicios de juegos. Servicios de juventud y adolescencia. Servicios de referencia. Servicios de mensajer´ıa. Servicios comerciales. Servicios de negocio. Servicios de salud. Servicios informativos. Servicios regionales (Estados Unidos). Servicios de sociedad. Servicios de ordenadores. 3.5. OPP-115 AUTOM ´ ATICA 35 Servicios del hogar. Servicios recreativos. Servicios de ciencias. Servicios inform´aticos. Servicios deportivos. En el an´alisis realizado destacamos que para cada servicio nos proporciona las distintas categor´ıas con un mayor nivel de detalle de seguimiento que cualquier otra fuente de datos, referenciando las distintas partes del documento de la pol´ıtica de privacidad donde tiene lugar y una calificaci´on del nivel de lectura de la pol´ıtica. En las ´areas de aplicaci´on en la que se va a desarrollar la integraci´on de servicios de correo y mensajer´ıa tenemos, dentro de los 115 documentos analizados, los siguientes servicios disponibles en la fuente de datos: Gmail, Hotmail y Yahoo!. 3.5. OPP-115 Autom´atica La ´ultima fuente de datos que se ha utilizado para obtener informaci´on de pol´ıticas de privacidad para los servicios seleccionados ha sido OPP-115 (Online Privacy Policies, set of 115) Autom´atica que proporciona Usable Privacy [9]. Se encarga del desarrollo y resoluci´on de los problemas de privacidad mediante un proyecto de pol´ıtica de privacidad utilizable en la cual para cada una de las categor´ıas de seguimiento que pueden hacer la organizaci´on al prestar el servicio, presenta los datos de forma que sea sencillo de determinar y filtrar para los usuarios. Es una versi´on ampliada de la fuente de datos anterior (OPP-115 Manual), que surge para resolver el problema de la limitaci´on del n´umero de servicios con sus pol´ıticas de privacidad analizadas. En esta nueva versi´on, se ampl´ıan a 7000 servicios, donde el prop´osito y finalidad por el que realizan el desarrollo es el mismo que para OPP-115 Manual, pero con una granularidad m´as gruesa, menor nivel de detalle en la clasificaci´on de las referencias al texto. La ´unica diferencia es que utilizan mecanismos automatizados basado en el an´alisis realizado para OPP-115 Manual. La categorizaci´on del tracking realizado es la misma y ´unicamente diferenci´andose de los algoritmos utilizados y que no es realizado por expertos 3.5.1. Abstracci´on A diferencia de lo que ocurre en la fuente de OPP-115 Manual, la informaci´on se presenta al usuario ´unicamente a trav´es de una interfaz de usuario y que nuevamente esa informaci´on de la interfaz tiene que ser alojada en alg´un almac´en f´ısico. Por ello, realizamos la abstracci´on para determinar c´omo estar´ıan alojados estos datos como si fuese una base de datos relacional. Con la informaci´on que nos proporciona, tenemos el esquema relacional resultante, junto con la explicaci´on de cada uno de los atributos asociados a la informaci´on que almacena: SERVICIO(nombre servicio, fuente, fecha version, nivel lectura) 36 CAP´ ITULO 3. FUENTES DE DATOS nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad que se describe. Formato del dato: Texto. fuente: Enlace al documento actual de la pol´ıtica de privacidad del servicio analizado. No se corresponde con el documento realmente analizado. Formato del dato: Texto. fecha version: Fecha relativa a la versi´on del documento de privacidad sobre el cual se ha realizado el an´alisis. Formato del dato: Fecha. nivel lectura: Nivel de legibilidad de la pol´ıtica de privacidad a trav´es de un nivel de grado de Estados Unidos (Flesch–Kincaid Grade Level). Formato del dato: Texto. DATOS(nombre servicio, categoria track, referencia texto) nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad que se describe. Formato del dato: Texto. categoria track: Categorizaci´on del texto de la pol´ıtica de privacidad. ´ Ambito de la tecnolog´ıa de seguimiento de la informaci´on por el servicio. Formato del dato: Texto. referencia texto: Texto resultante clasificado al que se hace referencia y describe para una categoria track de seguimiento. Formato del dato: Texto. 3.5.2. Formato de archivo y disponibilidad de los datos Los datos se encuentran accesibles a trav´es de una interfaz web. Se extraen ficheros en formato de texto JSON (JavaScript Object Notation) tras realizar un web scraping con herramientas para extraer informaci´on de su sitio web donde est´an presente los datos. Para obtener una respuesta, es necesario realizar una b´usqueda en un cuadro de texto por el nombre del servicio. Una vez realizada la b´usqueda, se elige una de las coincidencias que ha encontrado la interfaz web a esa b´usqueda del servicio, si es que est´a disponible. Nos proporciona el nombre del servicio y la URL para comprobar que realmente esa coincidencia de texto es la que estamos buscando. La fecha de incorporaci´on de los datos es del a˜no 2017 y la frecuencia de actualizaci´on de los datos presentes es muy baja. 3.5.3. Completitud de la fuente En cuanto al an´alisis realizado de pol´ıticas de privacidad, nuevamente tiene lugar en distintas ´areas, sin una clasificaci´on clara de las ´areas. Incluyen desde: Servicios de comercio electr´onico. Servicios de mensajer´ıa. Servicios bancarios. 3.6. VALORACI ´ ON GENERAL Y COMPARATIVA ENTRE FUENTES 37 Servicios de redes sociales. Servicios informativos y televisivos. Servicios de restauraci´on. Servicios de videojuegos. Servicios educativos. Servicios de salud. Servicios inmobiliarios. El an´alisis realizado destacamos que para cada servicio nos proporciona las distintas categor´ıas, con un nivel de detalle de seguimiento referenciando las distintas partes del documento de la pol´ıtica de privacidad donde tiene lugar y una calificaci´on del nivel de lectura de la pol´ıtica. En las ´areas de aplicaci´on en la que se va a desarrollar la integraci´on de servicios de correo y mensajer´ıa, tenemos los siguientes servicios disponibles en la fuente de datos: Gmail, Hotmail, Yahoo!, WhatsApp, Telegram, Discord, Messenger, iCloud, ProtonMail, Slack yTwitter. 3.6. Valoraci´on general y comparativa entre fuentes Una vez realizado el conocimiento en profundidad, con su descripci´on y desarrollo, nos damos cuenta de que cada una de ellas es similar en cuanto al prop´osito de su implementaci´on, pero presentan diferencias en cuanto al grado de detalle, refinamiento y servicios analizados. Tenemos tres grandes categor´ıas en las que poder realizar la comparaci´on: Actualizaci´on y frecuencia de las fuentes: La fuente que tiene un mayor nivel de actualizaci´on es ToS;DR, ya que constantemente est´an revisando las pol´ıticas de privacidad e incorporando nuevos casos de seguimiento conforme a las actualizaciones, evaluando y clasificando. Del mismo modo ampl´ıan incorporando an´alisis de nuevos servicios a esta fuente. Dejan un historial temporal visible de todos los casos introducidos. Por otro lado, la fuente con menor grado de actualizaci´on es OPP-115 Manual del a˜no 2015, y que posteriormente se ha utilizado como base para el estudio automatizado de los 7000 servicios que tiene OPP-115 Autom´atica, la cual desde que se elabor´o no se ha realizado ninguna actualizaci´on. Con respecto a los servicios de correo y de mensajer´ıa que analizamos, las ´ultimas modificaciones de algunos de sus documentos de pol´ıticas de privacidad han tenido lugar en: •Gmail: Febrero 2021. •Hotmail: Marzo 2021. •Yahoo!: Septiembre 2020. 38 CAP´ ITULO 3. FUENTES DE DATOS •WhatsApp: Enero 2021. •Telegram: Marzo 2021. •Discord: Junio 2020. •Wire: Mayo 2018. •Matrix: Agosto 2020. •Signal: Mayo 2018. La fecha de actualizaci´on de estas pol´ıticas est´a totalmente desacoplada de la de las fuentes de datos donde se almacenan. La mayor´ıa de las actualizaciones de sus documentos son del presente a˜no o anterior. De aqu´ı podemos sacar conclusiones para la toma de decisiones del tipo de almac´en de datos que se va a utilizar a la hora de integrar, junto con una pol´ıtica de actualizaciones. En principio, estas actualizaciones de las fuentes de datos ser´an baja o nula en cuanto a la variaci´on. En estos casos, el mecanismo utilizado ser´ıa el de un Warehouse que integre toda la informaci´on disponible, en detrimento del empleo de una integraci´on virtual usando un mediador, teniendo presente las ventajas e inconvenientes de utilizar uno u otro. Completitud: Un an´alisis realizado sobre una gran variedad de categor´ıas, clasificando cada servicio, ser´a m´as completa que una que solo cubre un determinado ´area y categor´ıas. Una fuente de datos que abarque un mayor n´umero de categor´ıas y en ellas est´e incluidos m´as servicios, ser´a mucho mejor para una posible escalabilidad que aquellas fuentes con servicios limitados. En nuestro caso, PrivaSeer es la que presenta una mayor categorizaci´on y un mayor n´umero de servicios analizados por categor´ıa. Mientras que OPP-115 Manual abarca gran variedad de categor´ıas, pero con pocos servicios analizados en cada una de ellas. En la mayor´ıa de los casos, aquellos an´alisis realizados por una persona especializada ser´a mejor que aquel que utiliza mecanismos automatizados para llevarlo a cabo. Por ello, OPP- 115 Manual realizado por expertos ser´a la m´as apropiada ya que tiene una categorizaci´on del seguimiento con un mayor grado de detalle. Del mismo modo, tambi´en tenemos ToS;DR, que es realizada por personas. Por otro lado, tanto PrivaSeer como OPP-115 Autom´atica utilizan mecanismos automatizados para obtener los resultados, partiendo de una base. Autor´ıa: En la autor´ıa, relacionado con el punto anterior, OPP-115 Manual emplea tres personas especializadas en derecho para realizar la lectura y filtrado del documento y su consecuente categorizaci´on del seguimiento. ToS;DR tambi´en emplea a las personas que quieran realizar una aportaci´on para su estudio y clasificaci´on. La parte negativa de esta ´ultima es que puede darse el caso de que estas personas puede que no tengan conocimientos acerca de ello, realizando aportaciones err´oneas y confusas. Para resolver el problema, se realizan revisiones finales por parte del personal de administraci´on de la fuente de informaci´on. En cuanto a PrivaSeer y OPP-115 Autom´atica utilizan algoritmos autom´aticos con determinada base de an´alisis del lenguaje natural para llevar a cabo el estudio del documento de las pol´ıticas de privacidad de los servicios que se analizan. 3.6. VALORACI ´ ON GENERAL Y COMPARATIVA ENTRE FUENTES 39 En la tabla 3.1 se puede ver la tabla comparativa entre las fuentes de datos para los criterios de actualizaci´on (Baja, Media, Alta), completitud (Baja, Media, Alta) y autor´ıa. Actualizaci´on Completitud Autor´ıa PrivaSeer Baja Alta Algoritmos ToS;DR Alta Media Personal OPP-115 Manua1 Baja Baja Personal especializado OPP-115 Autom´atica Baja Media Algoritmos Tabla 3.1: Comparaci´on de las fuentes de datos. 40 CAP´ ITULO 3. FUENTES DE DATOS Cap´ıtulo 4 Tecnolog´ıas utilizadas Una vez que ya se han descrito las fuentes de datos y la informaci´on que recogen por separado, necesitamos un mecanismo que se encargue de unificar toda esta informaci´on. En base a este an´alisis, tendr´ıamos que determinar cu´al ser´ıa nuestra arquitectura en uno de los tres m´etodos disponibles: integraci´on virtual, warehousing o mixto. Por un lado, en la integraci´on virtual, la informaci´on reside en las propias fuentes de datos siempre actualizadas, controlados por la organizaci´on que da el soporte. Por ello, puede darse el caso de tener problemas en el acceso a la fuente y eficiencia en el procesamiento. Las consultas se realizan directamente sobre los datos originales. Por el otro lado, en el warehousing, la informaci´on reside en un repositorio servidor donde el control ya no es de la organizaci´on que cre´o esa fuente de datos y esta informaci´on tiene que ir actualiz´andose peri´odicamente seg´un se realicen cambios desde las fuentes. Las consultas y procesos de anal´ıtica de datos ahora son m´as eficientes ya que no tenemos el problema de acceso a la fuente para cada consulta. Tambi´en veremos cu´ales han sido las tecnolog´ıas que se emplear´an para mostrar toda esa informaci´on al usuario. 4.1. Warehouse El concepto de Warehouse lo entendemos como un almac´en, en general. William H. Inmon desarroll´o almac´en de datos como “a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions. The data warehouse contains granular corporate data” [11]. Especific´andolo en el ´ambito que estamos desarrollando, un Data Warehouse se puede definir como un almac´en de datos que recoge toda la informaci´on que hay en cada una de las fuentes de pol´ıticas de privacidad. Sobre la informaci´on que hay recogida de car´acter descriptivo, se genera nueva informaci´on en forma de res´umenes, contabilizaciones e incluso se llega a un nivel superior de detalle para poder ofrecer informaci´on orientada a la toma de decisiones en cualquier momento, sin necesidad de esperar largos periodos en la realizaci´on de informes tediosos que tienen m´as probabilidad de error y acumulan un nivel muy superior de imprecisiones [12]. Es evidente el car´acter integrador que ofrece un Data Warehouse, no s´olo desde el punto de vista de recopilar informaci´on de todas las fuentes de datos que se use en la integraci´on final, sino desde el punto de vista de la calidad de la informaci´on. Un Data Warehouse puede ser 41 48 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS Datos brutos no integrados: Cuando se obtienen datos de varias fuentes de origen, los usuarios se quedan solos con la integraci´on de datos brutos. Esto puede convertirse en una tarea tediosa y propensa a errores. Baja calidad de los datos: A menudo los datos de las fuentes de origen tienen problemas con la calidad de los datos. Antes de utilizar los datos, es necesario limpiarlos con la transformaci´on para la obtenci´on del Data Warehouse. Datos brutos no consolidados: Para analizar los datos de m´ultiples fuentes de origen, los datos a menudo requieren consolidaci´on. Sin esta consolidaci´on, los resultados del an´alisis de la organizaci´on no tendr´an sentido. 4.2.5.3. Seguridad En la identificaci´on de riesgos con los que nos ´ıbamos a encontrar a la hora de desarrollar el proyecto de la secci´on 2.2, ya incluimos aspectos relacionados con la seguridad clasificando su impacto, probabilidad, indicador, plan de protecci´on y plan de contingencia. La p´erdida de informaci´on, corrupci´on de la informaci´on y la disponibilidad de las fuentes al hacer la integraci´on pueden afectarnos en la seguridad. La seguridad, como se establece en la Norma Internacional ISO / IEC 9126 [16], es uno de los componentes de la calidad del software. La seguridad de la informaci´on se puede definir como la preservaci´on de la confidencialidad, integridad y disponibilidad de la informaci´on, en el que la confidencialidad garantiza que la informaci´on sea accesible solo para aquellos usuarios con privilegios de autorizaci´on. La integridad protege la precisi´on, la integridad de la informaci´on y los m´etodos de proceso. Finalmente, la disponibilidad garantiza que los usuarios autorizados tengan acceso a la informaci´on y los activos asociados cuando sea necesario. Por lo tanto, la seguridad del almac´en de datos se define como los mecanismos que garantizan la confidencialidad, integridad y disponibilidad del almac´en de datos y sus componentes. Por un lado, para garantizar la protecci´on de los datos de un Data Warehouse tradicional, el mecanismo m´as sencillo, conocido y a su vez eficaz es llevando a cabo backups de forma peri´odica. Si embargo, estos backups suelen fallar a la hora de incluir los datos m´as recientes. La mejor copia de seguridad que puede realizarse es la que se hace lo m´as cerca posible del punto de fallo del sistema ya que de esta forma las incoherencias en torno a los datos del backup y los reales ser´an m´ınimas. En el otro lado, para conseguir una confidencialidad de los datos es necesario restringir y limitar los permisos y privilegios de los administradores del almac´en, con controles de acceso por clave y controlar el lugar donde va a residir este almac´en, si tendr´a conexiones habilitadas desde Internet o ser´a ´unicamente de almacenamiento local. Se deben realizar pruebas autom´aticas de seguridad de forma peri´odica para comprobar si existe alg´un tipo de vulnerabilidad, un funcionamiento correcto, sin que esto afecte a la operativa del sistema. 4.3. SQL SERVER INTEGRATION SERVICES 49 4.3. SQL Server Integration Services SQL Server Integration Services (SSIS) [17] es una plataforma para dar soluciones empresariales de transformaciones de datos e integraci´on de datos. Es un servicio ´util para resolver problemas complejos relacionados con la copia o descarga de archivos, la carga de almacenamientos de datos, la limpieza y miner´ıa de datos y la administraci´on de datos y objetos de SQL Server. Permite la extracci´on y transformaci´on de datos de diversos or´ıgenes como archivos de datos XML, CSV, JSON, archivos planos y or´ıgenes de datos relacionales y despu´es cargarlos en el destino. En su cat´alogo incluye un amplio conjunto de tareas y transformaciones integradas, herramientas gr´aficas para crear paquetes y bases de datos. La diferencia entre el proceso ETL y SSIS ser´ıa en que la denominaci´on de ETL se refiere a un concepto, mientras que SSIS es la herramienta desarrollada para trabajar con ese concepto ETL. 4.4. SQL Server Management Studio SQL Server Management Studio (SSMS) [18] es un entorno integrado para administrar cualquier infraestructura de SQL Server. Proporciona herramientas para configurar, supervisar y administrar instancias de SQL Server y bases de datos. Incorpora mecanismos para implementar, supervisar y actualizar los datos que usan la aplicaci´on web desarrollada. 4.5. Web scraping Como ya se ha mencionado en la descripci´on de las fuentes de datos, disponemos de una serie de informaci´on que podemos obtener de las pol´ıticas de privacidad en la que, sin embargo, en dos de estas la informaci´on no est´a accesible para poder ser descargada y manipularla como ocurren en las otras dos, a trav´es de una API o repositorio. Es por esto por lo que el mecanismo utilizado para obtener la informaci´on es la del web scraping (ara˜nar/raspar la web) [19], donde se extraen y almacenan datos de p´aginas web para analizarlos o utilizarlos en otra parte. Por medio de este scraping web se almacenan diversos tipos de informaci´on: datos de las pol´ıticas, referencias al texto analizado y clasificado, t´erminos de b´usqueda o URLs. Estos se almacenan en bases de datos locales, tablas o ficheros en diferentes formatos. Dentro del scraping hay diferentes modos de funcionamiento, diferenci´andose entre el scraping autom´atico y el manual. El scraping manual define el copiado y pegado manual de informaci´on y datos, si se desea encontrar y almacenar alguna informaci´on concreta. Es un proceso muy laborioso que raras veces se aplica a grandes cantidades de datos. En el caso del scraping autom´atico, se recurre a un software o un algoritmo que analiza diferentes p´aginas web para extraer informaci´on. Se utiliza software especializado seg´un el tipo de p´agina web y el contenido. Dentro del scraping autom´atico, se diferencian varios modos de proceder: 50 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS Analizador sint´actico: Los analizadores sint´acticos, tambi´en llamados parsers, se utilizan para convertir un texto en una nueva estructura. Bots: Un bot es un software dedicado a realizar determinadas tareas y automatizarlas. Se utilizan para examinar p´aginas web autom´aticamente y recopilar datos. Texto: Aprovechar la funci´on grep de Unix en l´ınea de comandos para buscar en la web determinados t´erminos en Python o Perl. Es un m´etodo sencillo para extraer datos. En este caso, la herramienta que se ha seleccionado para hacer el scraping de la web una vez analizado el formato de los datos ya disponibles para OPP-115 Manual y ToS;DR es ParseHub [20]. Permite realizar el scraping web de cualquier sitio, indicando la URL y seleccionando los ´ıtems interesados, navegando por distintas p´aginas. Las ventajas que dispone este software respecto al uso de otros ser´ıan: No dispone de restricci´on del m´aximo de tuplas recogidas. Facilidad de utilizaci´on. Variedad en el formato de los datos resultantes en CSV/XLS, JSON. Realizando el scraping sobre la fuente de datos OPP-115 Autom´atica, tenemos la desventaja de las interfaces en las que no hay navegaci´on y/o recarga de las p´aginas. S´olo se resaltan las frases y p´arrafos que incluyan alguna coincidencia con lo que se est´a seleccionando, manteniendo la misma p´agina. Por ello hay que definir 9 selectores, uno por cada categor´ıa, ya que no se hace referencia en cada categor´ıa a las mismas partes del texto, como si fuese est´atico. Una vez que se realizan dos selecciones en la parte del documento en una categor´ıa, el programa ya interpreta la selecci´on del resto del texto que est´a resaltado en color. En la parte izquierda, se pueden ir nombrando las columnas de las tablas o claves del JSON y el tipo de extracci´on que se realiza (texto, objetos, URL, elementos HTML). Seguidamente, en la parte inferior se puede observar en todo momento la estructura resultante en tiempo real seg´un se va realizando. Podemos guardar la estructura de scraping realizado y pasar a modo navegaci´on sin realizar ninguna selecci´on de un texto resaltado a otro. En la figura 4.2 se puede observar con detalle la p´agina principal sobre la cual se llevan a cabo todas estas operaciones. Una vez que se obtiene toda la informaci´on que nos interesa, en Get Data el programa nos lleva al sitio de la figura 4.3 donde realiza la extracci´on y procesa la informaci´on. La duraci´on depende, entre otros, del n´umero de elementos a extraer y la conexi´on disponible. Esta descripci´on del uso de la herramienta ParseHub para OPP-115 Autom´atica es igual para obtener la informaci´on en la interfaz de PrivaSeer. 4.5. WEB SCRAPING 51 Figura 4.2: Web scraping con ParseHub. Figura 4.3: Obtenci´on de los datos web scraping con ParseHub. 52 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS 4.6. Tecnolog´ıas web Para la construcci´on de una interfaz de usuario que muestre los datos al usuario, se utilizar´a una aplicaci´on web. En ella, se utilizar´an distintas tecnolog´ıas b´asicas y ampliamente extendidas en la actualidad. Al emplear una arquitectura cliente-servidor, se hace una distinci´on tanto para la parte del cliente como del servidor. 4.6.1. Tecnolog´ıas en la parte del cliente Las tecnolog´ıas utilizadas en la parte del Front-end para la conversi´on de los datos en una interfaz de usuario con la que el usuario interactuar´a son: HTML5: La versi´on 5 de HTML, que nos proporciona un lenguaje de marcado de hipertexto para la creaci´on y estructuraci´on de secciones, p´arrafos, encabezados y enlaces a trav´es de etiquetas y atributos. CSS3: La ´ultima versi´on de CSS para el control de toda la parte de estilos en los elementos escritos por medio de HTML, separando as´ı el contenido de su representaci´on visual. Ambas tecnolog´ıas son muy dependientes. JavaScript: Se utiliza la ´ultima versi´on 1.6 de JavaScript, junto con HTML y CSS para la implementaci´on de funciones en las p´aginas web y mejorar su estructura. Navegador web: Conformando la parte del cliente dentro de esa arquitectura cliente-servidor, para la recuperaci´on y representaci´on gr´afica de la Web. 4.6.2. Tecnolog´ıas en la parte del servidor Las tecnolog´ıas utilizadas en la parte del Back-end para dar soporte al sistema que se va a crear y tener accesibilidad a los datos son: Apache Tomcat: La versi´on 9.0 de Tomcat para conseguir un contenedor de servlets con todas sus especificaciones y las de los JavaServer Pages (JSP), funcionando como un servidor web. SQL Server: La versi´on 15.0 de SQL Server, que nos proporciona un Sistema Gestor de Base de Datos (SGBD) relacional, para dar servicio a la aplicaci´on a trav´es de su almacenamiento de datos y posterior consulta. Cap´ıtulo 5 An´alisis En la introducci´on de este proyecto ya mencionamos cual era el objetivo principal, la consulta de forma integrada de los metadatos de pol´ıticas de privacidad. Para ello, se construye un repositorio central que permita consultar informaci´on sobre c´omo se realiza el seguimiento, que informaci´on se comparte con terceras organizaciones, cu´ales son esas organizaciones, entre otros. En cualquiera que sea el proyecto de software que se realice necesitamos definir unos requisitos, servicios y restricciones que tendr´a el proyecto. 5.1. Tipos de consultas Al almacenar la informaci´on en un almac´en, debemos de alguna manera recuperar esa informaci´on, es decir, tiene que ser accesible para que la aplicaci´on web desarrollada tenga funcionalidad. Las consultas para realizar responden a las siguientes preguntas: ¿Cu´ales son las tecnolog´ıas utilizadas para hacer tracking? ¿Cu´ales son los datos y la finalidad con la que una organizaci´on recoge la informaci´on? ¿Dato y prop´osito con el que es compartido a una tercera parte la informaci´on? ¿Organizaci´on tercera con la que se comparte ese dato y elecciones del usuario de rechazo o modificaci´on de esa compartici´on? ¿Qu´e clasificaci´on tiene esa pol´ıtica en cuanto al tratamiento de los datos y su enlace al documento? Este tipo de preguntas nos sirve de ayuda entre la informaci´on que se ha extra´ıdo de las fuentes de datos para el Warehouse y posteriormente para describir los requisitos de informaci´on, junto con el dise˜no relacional de la informaci´on almacenada en la base de datos. 53 54 CAP´ ITULO 5. AN ´ ALISIS 5.2. An´alisis de la construcci´on del Warehouse 5.2.1. Requisitos En las siguientes secciones, describiremos cu´ales son los requisitos funcionales, no funcionales y de informaci´on que tendr´an los usuarios que utilicen el sistema desde el punto de vista de la construcci´on de un Data Warehouse. Para la realizaci´on de los procesos ETL, hay software especializado en la integraci´on de la informaci´on, y se ha buscado este software (SSIS) que nos ofrece una serie de caracter´ısticas para poder llevarlo a cabo desde el origen de los datos al destino. 5.2.1.1. Requisitos funcionales Los Requisitos Funcionales (RF) son la explicaci´on del funcionamiento y servicio que tendr´a el software utilizado en la construcci´on del Data Warehouse, junto con el comportamiento que tendr´a, interacciones de sistemas, respuestas y procesos. Los requisitos funcionales extra´ıdos de las fuentes de datos y la construcci´on del Data Warehouse a trav´es de este software ser´ıan: RF-01: El sistema deber´a permitir acceder a las fuentes de datos. RF-02: El sistema deber´a permitir leer informaci´on de las fuentes de datos. RF-03: El sistema deber´a permitir almacenar la informaci´on en el almac´en. RF-04: El sistema deber´a permitir actualizar la informaci´on del almac´en. 5.2.1.2. Requisitos no funcionales Los Requisitos No Funcionales (RNF), a diferencia de los requisitos funcionales, no hacen referencia directa a funciones que presta el sistema para las caracter´ısticas del usuario (lo que hace). Se centra en las propiedades y el funcionamiento que debe tener el sistema (c´omo lo hace). Define propiedades y restricciones que debe tener el sistema de integraci´on utilizado. Alternativamente, definen restricciones del sistema tales como la capacidad de los dispositivos de entrada/salida y la representaci´on de los datos utilizados en la interfaz del sistema. Tenemos tres tipos de requisitos no funcionales [21]: Requisitos del producto. Especifican el comportamiento del producto, como pueden ser los requisitos de desempe˜no en la rapidez de ejecuci´on del sistema y cu´anta memoria se requiere. Los de fiabilidad, que fijan la tasa de fallos para que el sistema sea aceptable. Tambi´en est´an los requisitos de portabilidad y los de usabilidad. Requisitos organizacionales. Se derivan de las pol´ıticas y procedimientos existentes en la organizaci´on del cliente y en la del desarrollador, es decir, est´andares en los procesos que deben utilizarse. Requisitos de implementaci´on como el m´etodo de dise˜no a utilizar. Requisitos externos. Se derivan de los factores externos al sistema. Incluyen los requisitos de interoperabilidad, que definen la manera en que el sistema interact´ua con los otros sistemas. 5.2. AN ´ ALISIS DE LA CONSTRUCCI ´ ON DEL WAREHOUSE 55 Por ello, los requisitos no funcionales del software que utilizamos para la construcci´on de este Data Warehouse con los procesos ETL ser´ıan: RNF-01: El sistema deber´a ser escalable en cuanto a fuentes de datos y servicios. RNF-02: El sistema deber´a garantizar la integridad y consistencia de los datos desde las fuentes. RNF-03: El sistema deber´a garantizar la detecci´on de errores y recuperaci´on de ellos. RNF-04: El sistema deber´a implementar mecanismos de actualizaci´on. RNF-05: El sistema deber´a garantizar un tiempo de carga de informaci´on lo m´as corto posible. RNF-06: El sistema deber´a garantizar la disponibilidad en todo momento. RNF-07: El sistema deber´a ser f´acil de mantener. 5.2.1.3. Requisitos de informaci´on Tras realizar la abstracci´on de la informaci´on que est´a disponible en las fuentes de datos en cap´ıtulos anteriores y tras realizar una clasificaci´on de la informaci´on que ir´a en el Warehouse, los Requisitos de Informaci´on (RI) que ser´an necesarios extraer desde las fuentes de datos, a trav´es de este software utilizado para la integraci´on ser´an: RI-01: El sistema deber´a almacenar informaci´on del servicio. Nombre Fuente Versi´on Fecha Clasificaci´on RI-02: El sistema deber´a almacenar informaci´on de los datos que recopila y almacena una organizaci´on. Nombre Fuente Versi´on Fecha Dato 56 CAP´ ITULO 5. AN ´ ALISIS Finalidad RI-03: El sistema deber´a almacenar informaci´on de las terceras partes. Nombre Fuente Versi´on Fecha Dato Prop´osito Tercero Elecci´on RI-04: El sistema deber´a almacenar informaci´on de la forma que realiza el seguimiento. Nombre Fuente Categor´ıa 5.3. An´alisis de la aplicaci´on de consulta 5.3.1. Requisitos Una vez que hemos definido las tres categor´ıas de requisitos que hay (funcional, no funcional y de informaci´on), y se han determinado cu´ales son para obtener la informaci´on de las fuentes de datos para construir el Data Warehouse, determinamos ahora cu´ales ser´an los requisitos que tendremos en cada una de las categor´ıas para la construcci´on de la aplicaci´on de consulta. 5.3.1.1. Requisitos funcionales RF-01: El sistema deber´a permitir mostrar el enlace a la pol´ıtica de privacidad. RF-02: El sistema deber´a permitir recuperar la informaci´on de la clasificaci´on de un servicio. RF-03: El sistema deber´a permitir consultar por un determinado dato. RF-04: El sistema deber´a permitir la consulta de la finalidad de un dato. RF-05: El sistema deber´a permitir consultar por el dato compartido con terceras partes. 5.3. AN ´ ALISIS DE LA APLICACI ´ ON DE CONSULTA 57 RF-06: El sistema deber´a permitir obtener el prop´osito de la informaci´on que ha sido compartida. RF-07: El sistema deber´a permitir consultar qui´en es la tercera parte con la que se comparte ese dato. RF-08: El sistema deber´a permitir recuperar informaci´on sobre la posibilidad de concesi´on o revocaci´on de los datos cedidos. RF-09: El sistema deber´a permitir consultar c´omo una organizaci´on recoge la informaci´on del usuario. RF-10: El sistema deber´a permitir la descarga/exportaci´on de los datos buscados. 5.3.1.2. Requisitos no funcionales RNF-01: El sistema deber´a ejecutarse en cualquier navegador con HTML5. RNF-02: El sistema deber´a desplegarse en varios Sistemas Operativos. RNF-03: El sistema deber´a ser f´acil de mantener. RNF-04: El sistema deber´a garantizar la integridad de los datos. RNF-05: El sistema deber´a asegurar la consistencia de la informaci´on almacenada. RNF-06: El sistema deber´a garantizar la detecci´on de errores y recuperaci´on de ellos. RNF-07: El sistema deber´a obtener informaci´on actualizada. RNF-08: El sistema deber´a responder correctamente y comprobar las entradas incorrectas del usuario. RNF-09: El sistema deber´a tener un tiempo de respuesta no superior a 3 segundos. RNF-10: El sistema deber´a implementar mecanismos de seguridad de inyecci´on de c´odigo. 5.3.1.3. Requisitos de informaci´on Los requisitos de informaci´on en este caso son los mismos que para el acceso a los datos y construcci´on del Warehouse ya que en ambas situaciones accedemos a la base de datos, es decir, el almac´en que tiene el mismo esquema relacional. 5.3.2. Casos de uso Un diagrama de casos de uso representa el comportamiento del sistema desde el punto de vista del usuario (actor). Este actor no tiene que ser una persona, puede ser cualquier proceso o sistema externo que interact´ua con el sistema. Se utiliza para mostrar la relaci´on existente entre un actor y los requisitos funcionales descritos anteriormente, sin una descripci´on de las acciones que ocurren. El diagrama de casos de uso 64 CAP´ ITULO 6. DISE ˜ NO finalidad: Texto de la pol´ıtica de privacidad donde se indica la finalidad para la que se recoge el dato. TERCERO(id tercero, id pol, nombre servicio, fuente, dato, proposito, tercero, eleccion usuario) id tercero: Identificador ´unico que asigna el almac´en al dato recogido y compartido con terceros. id pol: Identificador ´unico que asigna el almac´en a la pol´ıtica de privacidad que se describe. nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad. fuente: Enlace al documento de la pol´ıtica de privacidad m´as reciente del servicio. dato: Nombre del dato recogido por el servicio, seg´un se indica en la pol´ıtica de privacidad cuya URL aparece. proposito: Finalidad para la que se recoge el dato o que se ha encontrado en una fuente. tercero: Servicio al que se ceden los datos, seg´un aparece en la pol´ıtica de privacidad que se describe. eleccion usuario: Indica si el usuario puede optar por ceder el dato o rechazarlo. TRACKING(id track, id pol, nombre servicio, fuente, categoria) id track: Identificador ´unico que asigna el almac´en al seguimiento realizado para un servicio. id pol: Identificador ´unico que asigna el almac´en a la pol´ıtica de privacidad que se describe. nombre servicio: Nombre ´unico del servicio de la pol´ıtica de privacidad. fuente: Enlace al documento de la pol´ıtica de privacidad m´as reciente del servicio. categoria: Tipo de tecnolog´ıa utilizada para hacer el tracking (seguimiento). 6.1.3. Dise˜no f´ısico La realizaci´on de un dise˜no f´ısico nos permite optimizar el rendimiento futuro que tendr´a el Data Warehouse, asegurando todas las restricciones de integridad de entidad y referencial. En esta etapa, las entidades definidas se transforman en las tablas que lo conforman, las instancias en filas y los atributos en columnas. Como´ındices, las claves primarias de las tablas se transforman en´ındices primarios y las claves for´aneas pasan a formar ´ındices secundarios. De este modo, podremos optimizar las b´usquedas. La transformaci´on realizada, junto con los tipos de los datos utilizados, est´an en las tablas 6.1 a 6.4. 6.1. DISE ˜ NO DE LA CONSTRUCCI ´ ON DEL WAREHOUSE 65 SERVICIO Atributo Tipo de datos id pol int nombre servicio nvarchar(50) fuente nvarchar(250) URL version analizada nvarchar(250) fecha version date clasificacion nvarchar(4) Tabla 6.1: Dise˜no f´ısico tabla Servicio DATO Atributo Tipo de datos id dato int id pol int nombre servicio nvarchar(50) fuente nvarchar(250) URL version analizada nvarchar(250) fecha version date dato nvarchar(3000) finalidad nvarchar(3000) Tabla 6.2: Dise˜no f´ısico tabla Dato TERCERO Atributo Tipo de datos id tercero int id pol int nombre servicio nvarchar(50) fuente nvarchar(250) dato nvarchar(1000) proposito nvarchar(1000) tercero nvarchar(1000) eleccion usuario nvarchar(500) Tabla 6.3: Dise˜no f´ısico tabla Tercero TRACKING Atributo Tipo de datos id track int id pol int nombre servicio nvarchar(50) fuente nvarchar(250) categoria nvarchar(500) Tabla 6.4: Dise˜no f´ısico tabla Tracking 66 CAP´ ITULO 6. DISE ˜ NO 6.2. Dise˜no de la aplicaci´on de consulta En el momento de determinar cu´ales eran las posibles soluciones en las que se podr´ıa aportar la funcionalidad del sistema al usuario, se consider´o la utilizaci´on de Java con implementaci´on Web. Por un lado, el usuario no tiene que descargar aplicaciones o ejecutables. Por el otro lado, Java es un lenguaje con orientaci´on al objeto, donde podemos almacenar informaci´on que posteriormente se recuperar´a y mostrar´a al usuario. 6.2.1. MVC Para definir la arquitectura software del proyecto, entre los patrones de dise˜no que hay y al tener una interfaz de usuario en la que el usuario interact´ua con el sistema, el patr´on m´as apropiado de utilizar es el MVC (Modelo Vista Controlador). Figura 6.4: Modelo Vista Controlador. El funcionamiento del patr´on MVC de la figura 6.4 se fundamenta en: 1. El navegador del usuario (web browser) genera una petici´on HTTP. 2. El controlador, un Servlet que funciona a modo de servidor entre el usuario y servidor de los datos, recoge esta petici´on de interacci´on. 3. El controlador solicita los datos al modelo (las clases Java). 4. El modelo devuelve los datos tras la consulta en la base de datos. 5. El controlador selecciona una vista. 6.2. DISE ˜ NO DE LA APLICACI ´ ON DE CONSULTA 67 6. Se devuelve la vista que ha seleccionado al controlador. 7. El controlador proporciona la vista (JSP) al navegador con los nuevos datos cargados del modelo. 6.2.2. Arquitectura l´ogica Para la arquitectura l´ogica de la figura 6.5 que determinar´a c´omo se interactuar´a con el c´odigo fuente del software, se ha utilizado un diagrama de paquetes a alto nivel para su representaci´on, sin entrar en profundidad de los distintos elementos que lo componen, cu´ales son los principales eventos que recoger´a el controlador (buscar informaci´on, filtrar informaci´on y descargar informaci´on) y que desencadenar´an cambios en las partes m´as internas. Dominio con todas las clases utilizadas para almacenar la informaci´on obtenida de la base de datos. Finalmente, en Utilidades se implementar´a todo lo relativo con el acceso a los datos, con su conexi´on y la base de datos empleada. Figura 6.5: Arquitectura l´ogica aplicaci´on. 6.2.3. Diagrama de clases de dise˜no El diagrama de clases de dise˜no especifica las clases software que tendr´a una aplicaci´on. A diferencia de los diagramas de clases utilizados en la fase de an´alisis, este presenta las entidades que almacenar´an informaci´on y sus conexiones con m´as semejanza a su implementaci´on final. Las clases est´an formadas por los atributos donde almacena la informaci´on de esa entidad y las operaciones que para un determinado caso de uso es necesario llevar a cabo. 68 CAP´ ITULO 6. DISE ˜ NO Figura 6.6: Modelo de dominio de dise˜no. Este tipo de diagramas, junto con los diagramas de secuencia de la siguiente secci´on, implementan las operaciones que tendr´an lugar a la hora de realizar los casos de uso. Para la realizaci´on de caso de uso central del proyecto con la b´usqueda de informaci´on, y que se realizar´a dicho diagrama de secuencia en la siguiente secci´on, en la figura 6.6 se puede ver c´omo va desde la parte m´as externa y visible al usuario con la que interactuar´a a la parte m´as interna. La parte externa se conforma mediante vistas, que corresponden con la p´agina de inicio y la p´agina de resultados obtenidos tras la consulta. La parte intermedia est´a compuesta por el controlador “Consulta”, que revisa todas las peticiones del usuario y redirige a nuevas vistas de resultado junto con los datos. Posteriormente tenemos toda la parte m´as interna con el modelo, que se encarga de obtener los datos que desea el usuario en objetos solicitados por el controlador, dependiendo del tipo de consulta que realice, a trav´es de una conexi´on con la base de datos. Finalmente, se encuentra la base de datos final de SQL Server, sobre la que se establecen conexiones desde el modelo para obtener resultados de las consultas del usuario. 6.2.4. Diagrama de secuencia El diagrama de secuencia que se ha realizado en la figura 6.7 se corresponde con el caso de uso principal del proyecto, b´usqueda de datos, m´as en concreto, datos de primeras partes. Este diagrama nos permite especificar el comportamiento que tendr´a el sistema ante esa interacci´on del usuario, es decir, el desarrollo de los requisitos de la secci´on anterior. Permiten determinar 6.2. DISE ˜ NO DE LA APLICACI ´ ON DE CONSULTA 69 cu´al ser´a la secuencia de los mensajes intercambiados entre los objetos, desde el inicio hasta la finalizaci´on del caso de uso. Cada objeto est´a representado como una l´ınea de vida y focos de control, para indicar el tiempo de existencia del objeto. El actor usuario introduce la informaci´on del servicio en la p´agina de inicio por medio de un formulario, para consultar los datos de primeras partes. Este genera una petici´on HTTP de tipo GET, que es recibido por el servlet y a partir de aqu´ı genera el resto de la secuencia de mensajes. Crea una lista de Dato del modelo, que obtiene una conexi´on de la base de datos y ejecuta la consulta para obtener los resultados de la b´usqueda realizada. Posteriormente, mientras tengamos los resultados de la consulta a la base de datos en un conjunto de resultados, se van creando objetos de tipo Dato para a˜nadirlos a la lista de Dato. Una vez finalizado, el servlet selecciona la p´agina de la vista que mostrar´a al usuario. Esta nueva p´agina JSP lee los datos que recibe de la lista, y los muestra en el lugar adecuado de la p´agina. Se reenv´ıa la p´agina al usuario y finalmente, tiene lugar la respuesta HTTP. Figura 6.7: Diagrama de secuencia b´usqueda de datos. 70 CAP´ ITULO 6. DISE ˜ NO 6.2.5. Arquitectura f´ısica En la arquitectura f´ısica de la figura 6.8, se determina c´omo se llevar´a a cabo su implementaci´on en dispositivos. El servicio web que se est´a ejecutando en la m´aquina del usuario est´a soportada por una base de datos donde almacena toda esta informaci´on que ser´a actualizada en funci´on de los datos que desea obtener. Por ello, se utiliza el esquema b´asico y t´ıpico sin muchas variantes de soluciones est´andar para organizaciones est´andar en niveles. En este caso local que estamos desarrollando, el web browser del cliente que tiene la interfaz de usuario, est´a conectado al servidor web a trav´es de internet que a su vez se conecta al servidor de aplicaciones, para las ejecuciones del servidor de aplicaciones de la aplicaci´on que se desarrollar´a con su contenido din´amico. Este servidor de aplicaciones finalmente est´a conectado con el servidor de base de datos para proporcionarnos la l´ogica din´amica usando un protocolo de conexi´on con la base de datos INT BD. Figura 6.8: Arquitectura f´ısica aplicaci´on. Cap´ıtulo 7 Implementaci´on En este cap´ıtulo del proyecto se describe c´omo se ha realizado el proceso final de construcci´on del Warehouse y la posterior aplicaci´on web. Como venimos haciendo en los dos ´ultimos cap´ıtulos, el proceso est´a dividido en dos partes. Una la que concierne todo lo relacionado con el proceso de carga en el Data Warehouse y la otra relacionado con la puesta en funcionamiento de la consulta de la informaci´on de ´el. Este cap´ıtulo es uno de los m´as importantes ya que se explicar´a todo el proceso de construcci´on de ambas partes, paso a paso, detallado en algunas zonas y extrapolables para el resto. 7.1. Implementaci´on de la construcci´on del Warehouse 7.1.1. Creaci´on de la estructura Antes de empezar a realizar la carga de informaci´on en la base de datos, debemos tener construida la base de datos y las tablas que se poblar´an con la informaci´on. El proceso ETL ´unicamente coge los datos del origen y los lleva a un destino, por lo que tenemos que definir un DDL (Data Definition Language). Este DDL define los objetos, estructuras, relaciones y restricciones que tendr´an las tablas de una base de datos. En nuestro caso, el DDL estar´a compuesto por cuatro consultas de tipo CREATE TABLE, una por cada una de las tablas que se van a utilizar, sus respectivas restricciones de integridad de entidad y referencial y sus ´ındices. 7.1.2. Usuarios y permisos En la etapa de an´alisis ya identificamos los usuarios (actores) que iban a interactuar en nuestro sistema: Usuario y Administrador. Cada uno de ellos accede a distintas partes del sistema y es necesario que tenga distinto rol en el Data Warehouse, con permisos de la tabla 7.1. 71 72 CAP´ ITULO 7. IMPLEMENTACI ´ ON Usuario Permisos Administrador CRUD Usuario R Tabla 7.1: Permisos y usuarios. Donde CRUD hacer referencia al acr´onimo traducido como Crear, Leer, Actualizar y Borrar de las funciones b´asicas realizadas sobre una base de datos. Desde el Sistema Gestor de Base de Datos SQL Server, se configuran los usuarios y permisos que tendr´an. Para la configuraci´on del nuevo Usuario, se siguen los siguientes pasos: 1. Accedemos como administrador al servidor final de la base de datos con SQL Server Management Studio. 2. Acedemos al directorio Logins, que es un subdirectorio de Security y seleccionamos New Login. 3. En el desplegable, en la pesta˜na General, introducimos los nuevos datos de inicio de sesi´on: nombre y contrase˜na. 4. En la pesta˜na User Mappings de la figura 7.1, seleccionamos la base de datos y la pertenencia al rol de la base de datos db datareader y guardamos cambios. Figura 7.1: Creaci´on de usuario y permisos. 7.1. IMPLEMENTACI ´ ON DE LA CONSTRUCCI ´ ON DEL WAREHOUSE 73 7.1.3. Proceso de carga de datos En esta secci´on se explican los elementos que dispone SQL Server Integration Services para realizar la integraci´on de la informaci´on. Es importante diferenciar las dos estrategias de carga: INSERT: Si no existe un registro que ya est´e insertado con mismo nombre o fuente, se inserta uno nuevo para el mismo. UPDATE: Si ya existe un registro insertado con un mismo nombre o fuente, se realiza una actualizaci´on de aquellos atributos que se han podido modificar. La carga de los datos base se realiza una ´unica vez, pero al trabajar con un Data Warehouse donde las fuentes de datos pueden realizar modificaciones, es necesario definir un mecanismo de actualizaci´on. Para generar los procesos ETL se utiliza un software espec´ıfico para la integraci´on de informaci´on, SQL Server Integration Services (SSIS) que permite mover datos de origen a destino, sin modificar estas fuentes y realizar las transformaciones y cambios para incorporarlos finalmente en el destino. Para usar esta herramienta, hacemos uso de Visual Studio con un proyecto de Integration Services. De esta manera, vamos a poder conectarnos m´as f´acil al destino, una base de datos relacional de SQL Server. Despu´es de introducir los par´ametros de configuraci´on de la administraci´on de conexiones OLEDB (SQL Server) y poder seleccionar la base de datos del servidor donde se realizar´a la carga, se crea un nuevo paquete de SSIS. Una vez creado el nuevo paquete de SSIS, se incorpora al lienzo de “flujo de control” una tarea “flujo de datos”. Las configuraciones que podemos a˜nadir a este flujo son: Or´ıgenes de datos: Los or´ıgenes de datos se encargan de la recogida de los ficheros sobre los que se va a realizar el ETL. En nuestro caso, el tipo de ficheros ser´a de formato JSON y CSV. El problema que tiene Microsoft Integration Services Project es que hay que incorporar el paquete SSIS PowerPack [23] para poder obtener informaci´on de diferentes formatos de ficheros que la versi´on inicial de MISP no dispone. Otros or´ıgenes ser´an tablas de nuestro Warehouse para obtener determinados campos en la carga de ciertos datos. Salida de errores: Si se produce alg´un error en alg´un registro que no es le´ıdo, podemos redirigir esta salida de error a un fichero de texto plano. Se utilizar´an en los or´ıgenes y destinos para comprobar que la extracci´on y carga se realiza correctamente. Conversi´on de datos: El propio sistema identifica el tipo de datos que tiene el origen. Sin embargo, para hacer concordancia de tipos, podemos seleccionar manualmente aquellos atributos y el tipo de esos datos en el destino. B´usqueda: Se establece una conexi´on con una tabla de la base de datos de destino. Se determina el campo de comparaci´on con el origen. Dependiendo del resultado de la comparaci´on, podemos redirigir unas filas para un destino y otras para otro. Divisi´on condicional: Nos permite redirigir el flujo de determinados registros de entrada a distintos elementos de salida, en base a condiciones. 80 CAP´ ITULO 7. IMPLEMENTACI ´ ON Figura 7.5: ETL OPP-115 Manual Tracking. 6. Ordenar: En todos los elementos de ordenaci´on empleados, tiene como objetivo ordenar en base a un elemento, para poder realizar una “Combinaci´on de mezcla”. 7. Combinaci´on de mezcla: Se realiza un JOIN entre los elementos que se reciben, tanto de la parte izquierda del origen de las fuentes de datos como de la parte derecha con datos ya almacenados en el Warehouse, ordenados, para obtener datos del servicio. 8. B´usqueda: Realiza una b´usqueda con los elementos que ya est´an en nuestra tabla, haciendo un JOIN entre la tabla temporal del origen y la de destino. 9. Divisi´on condicional: Recibe el resultado de la b´usqueda, se comprueban que ninguno de los datos sea nulo y que el dato sea nuevo (para insertar) o existente (para actualizar). En funci´on de su salida, redirige las filas al siguiente elemento. 10. Destino de TRACKING: Es la base de datos de destino, donde recibe los nuevos registros que finalmente ser´an cargados en nuestra tabla TRACKING. 11. Comando de TRACKING: Ejecuci´on de la consulta UPDATE, con los par´ametros de filas que recibe de la divisi´on condicional. 12. Destino de archivo error origen: Fichero con informaci´on de las filas con error que no se pudieron cargar del origen y el tipo de error. 13. Destino de archivo error origen 1: Fichero con informaci´on de las filas con error que no se pudieron cargar de la base de datos y el tipo de error. 14. Destino de error inserci´on: Fichero con informaci´on de las filas con error que no se insertaron en la tabla de destino y tipo de error. 7.1. IMPLEMENTACI ´ ON DE LA CONSTRUCCI ´ ON DEL WAREHOUSE 81 15. Destino de error actualizaci´on: Fichero con informaci´on de las filas con error, que ten´ıan que actualizarse y que no se pudieron actualizar en la tabla y el tipo de error. El mapeo de datos resultante desde la fuente origen al Data Warehouse destino ser´ıa el de la tabla 7.5. Origen Destino SERVICIO.id pol id pol SERVICIO.nombre servicio nombre servicio Column9 fuente $.“Action First-Party”.value categoria Tabla 7.5: Mapeo origen-destino Tracking OPP-115 Manual. 7.1.6. Proceso ETL PrivaSeer Como ya hemos explicado en el cap´ıtulo de abstracci´on de las fuentes de datos, cada fuente analiza distintos servicios y granularidad de las pol´ıticas de privacidad. Por ello, se completa con informaci´on que, aunque no est´e completa, permite incorporar los datos de estos servicios que han sido analizados por distinta fuente. En este caso, el ETL resultante de los datos para PrivaSeer ser´ıa el de la figura 7.6. Figura 7.6: ETL PrivaSeer Dato. La explicaci´on de cada elemento utilizado de la figura 7.6 ser´ıa: 1. JSON Source: Configuraci´on del origen de la informaci´on para la extracci´on de un fichero en JSON de PrivaSeer. 82 CAP´ ITULO 7. IMPLEMENTACI ´ ON 2. Origen de DB: Datos que ya residen en el Warehouse para obtener informaci´on del servicio que se va a cargar. 3. Ordenar: En todos los elementos de ordenaci´on utilizados, tienen como objetivo ordenar en base a un elemento y eliminar los duplicados, para poder realizar una “Combinaci´on de mezcla”. 4. Combinaci´on de mezcla: Se realiza un JOIN entre los elementos que se reciben tanto de la parte izquierda con el origen, como de la parte derecha con lo ya almacenado en el Warehouse, ordenados, para obtener datos del servicio. 5. B´usqueda: Realiza una b´usqueda con los elementos que ya est´an en nuestra tabla, haciendo un JOIN entre la tabla temporal de origen y la de destino. 6. Divisi´on condicional: Recibe el resultado de la b´usqueda y se comprueban que ninguno de los datos sea nulo y que el dato sea nuevo (para insertar) o existente (para actualizar). En funci´on la salida de su condici´on (“Nuevo” o “Actualiza”), redirige las filas al siguiente elemento. En cualquier otro caso (no es nuevo ni se ha actualizado), la carga queda sin efecto. 7. Destino de DATO: Es la base de datos de destino, donde recibe los nuevos registros que finalmente ser´an cargados en nuestra tabla DATO. 8. Comando de DATO: Ejecuci´on de la consulta UPDATE, con los par´ametros de filas que recibe de la divisi´on condicional. 9. Destino de error origen: Fichero con informaci´on de las filas con error que no se pudieron cargar del origen y el tipo de error. 10. Destino de error origen 1: Fichero con informaci´on de las filas con error que no se pudieron cargar de la base de datos y el tipo de error. 11. Destino de error inserci´on: Fichero con informaci´on de las filas con error que no se insertaron en la tabla destino y tipo de error. 12. Destino de error actualizaci´on: Fichero con informaci´on de las filas con error para actualizar, que no se pudieron actualizar en la tabla y el tipo de error. El mapeo de datos resultante ser´ıa el de la tabla 7.6. Origen Destino SERVICIO.id pol id pol $.nombre servicio nombre servicio $.fuente fuente $.fecha version fecha version $.“categoria track” dato Tabla 7.6: Mapeo origen-destino Dato PrivaSeer. 7.2. IMPLEMENTACI ´ ON DE LA APLICACI ´ ON DE CONSULTA 83 7.2. Implementaci´on de la aplicaci´on de consulta Una vez que ya se ha realizado todo el proceso de an´alisis de requisitos y dise˜no de arquitectura l´ogica y f´ısica, es necesario plasmar todo en la aplicaci´on que los usuarios podr´an consultar. En este momento ya disponemos del Data Warehouse que soportar´a nuestra aplicaci´on para la consulta de informaci´on. Las librer´ıas y los lenguajes utilizados para la construcci´on de la aplicaci´on han sido: HML5 para la generaci´on de vistas. CSS3 y JavaScript 1.6 para los dise˜nos de la interfaz. Adicionalmente la biblioteca Bootstrap 3.3.7 para plantillas de dise˜no y simplificaci´on. JavaScript 1.6 y jQuery 3.5.1 para todo lo relacionado con la interfaz, validaciones, interacciones y animaciones. HikariCP para proporcionarnos un grupo de conexiones JDBC listo para usar y reutilizar conexiones sin gastos generales. JSTL para utilidades de desarrollo din´amico de p´aginas con los JSP, consultando f´acilmente los datos, pudiendo tener nuestra biblioteca de etiquetas. SLF4J para implementaci´on de logs, una fachada que implementa los loggers. OpenCSV para la implementaci´on de forma sencilla de documentos CSV con la descarga de los datos. 7.2.1. Clases Controlador Como ya hemos visto cuando se ha realizado la descripci´on del patr´on MVC, tendremos una serie de controladores para las acciones del usuario, que gestionan esas peticiones que se realizan. Cualquier llamada e interacci´on pasa obligatoriamente por un controlador. Esta clase controlador hereda de HttpServlet, con dos m´etodos de clase importantes, el doGet ydoPost. El primero recibe los par´ametros por par´ametro en la URL, mientras que el segundo oculta estos par´ametros. En la implementaci´on de nuestro caso, se han utilizado ambas indistintamente dependiendo de la situaci´on, ya que la informaci´on con la que estamos tratando no es sensible. En esta clase se produce la creaci´on de los objetos y la posterior consulta sobre la base de datos. Finalmente, el controlador tiene que redireccionar a una vista con la informaci´on que se ha solicitado. 7.2.2. Clases Modelo Las clases modelo, como vimos en el patr´on de MVC, son las encargadas de realizar las operaciones con la base de datos. 84 CAP´ ITULO 7. IMPLEMENTACI ´ ON En ellas, se definen los objetos que tendr´a el sistema, los atributos y los constructores con la informaci´on que se almacena en ellos. Se utilizan las clases que se han definido en los diagramas de dise˜no del cap´ıtulo anterior (Servicio, Dato, Tercero, Tracking). En las consultas (query) que se realicen en una base de datos, se emplear´an consultas parametrizadas para proporcionar seguridad y prevenir ataques de inyecci´on de c´odigo. 7.2.3. Clase Conexi´on Para la implementaci´on de la conexi´on con el servidor de la base de datos desde la aplicaci´on, y obtener los datos de estos en consultas, se utiliza la librer´ıa HikariCP [24]. HikariCP nos proporciona un connection pool (grupo de conexiones), donde permite el manejo de una colecci´on de conexiones abiertas a una base de datos, de manera que estas conexiones puedan ser reutilizadas al realizar m´ultiples consultas a la base de datos. Permite la configuraci´on de una serie de par´ametros de seguridad, como el tama˜no m´aximo de conexiones, d´onde reside el servidor con los datos, autenticaci´on del usuario que se conecta, entre otros. 7.2.4. Vistas de la aplicaci´on Las vistas utilizadas son ficheros con extensi´on JSP. Utilizan CSS para la elaboraci´on de los estilos y c´omo se mostrar´a al usuario. Mientras que las p´aginas HTML nos proporcionan la parte est´atica, los JSP son los que nos van a permitir crear una p´agina web din´amica utilizando el lenguaje Java. Con JSP Expression Language de JSTL, accedemos a la informaci´on de los objetos del modelo obtenidos de la base de datos, que se va a cargar en la vista. Adicionalmente se utilizan jQuery y JavaScript para funcionalidades concretas de mostrar/ocultar elementos de la vista y validaci´on de las entradas. Cap´ıtulo 8 Pruebas Una de las etapas m´as importantes del proyecto una vez que ya se ha elaborado la aplicaci´on son las pruebas. Los casos de prueba nos permiten determinar si finalmente el sistema desarrollado cumple con las especificaciones, sin errores y con el comportamiento deseado logra su cometido. Previamente a la elaboraci´on de la aplicaci´on, es necesario obtener los datos con la construcci´on del Data Warehouse. Para su construcci´on, como vimos en el cap´ıtulo de implementaci´on, se utiliza SQL Server Integration Services como software integrador. En el ap´endice A se puede visualizar las pruebas que se han realizado de su correcto funcionamiento del flujo de carga y ejecuci´on de procesos ETL. 8.1. Pruebas de funcionamiento general En el lado de la aplicaci´on, las pruebas de caja negra m´as significativas para el proyecto se detallan en las siguientes tablas. Los casos de prueba de las tablas 8.1 a 8.5 se corresponden con pruebas de b´usqueda de informaci´on para un servicio. P-01 Informaci´on y valoraci´on de un servicio. Descripci´on Petici´on de informaci´on y la valoraci´on que tiene un servicio. Entrada Select: Fuente y valoraci´on del uso de la informaci´on de un servicio. Servicio: Google. Salida esperada Tarjeta con datos de la valoraci´on de Google y enlace a la pol´ıtica de privacidad. Salida obtenida Salida esperada. Tabla 8.1: P-01: Informaci´on y valoraci´on de un servicio. 85 86 CAP´ ITULO 8. PRUEBAS P-02 Tecnolog´ıas de tracking. Descripci´on Petici´on de informaci´on de las tecnolog´ıas de tracking de un servicio. Entrada Select: Tecnolog´ıas utilizadas para hacer tracking. Servicio: Microsoft. Salida esperada Listado con todas las categor´ıas de seguimiento de Microsoft. Salida obtenida Salida esperada. Tabla 8.2: P-02: Tecnolog´ıas de tracking. P-03 Datos y finalidad de los datos recogidos. Descripci´on Solicitud de informaci´on de los datos de primeras partes y finalidades de esos datos empleados de un servicio. Entrada Select: Datos y finalidad por la que la organizaci´on recoge la informaci´on. Servicio: Microsoft. Salida esperada Acorde´on desplegable con los datos y finalidad de Microsoft, clasificado por el dato recogido. Salida obtenida Salida esperada. Tabla 8.3: P-03: Datos y finalidad de los datos recogidos. P-04 Organizaciones compartidas y revocaci´on. Descripci´on Informaci´on de las organizaciones con las que se comparten datos y posibilidades de revocaci´on. Entrada Select: Organizaciones con la que se comparten los datos y elecciones de usuario. Servicio: Yahoo! Salida esperada Acorde´on desplegable con las organizaciones y elecci´on de usuario para Yahoo!, clasificado por las organizaciones. Salida obtenida Salida esperada. Tabla 8.4: P-04: Organizaciones compartidas y revocaci´on. P-05 Dato compartido y prop´osito. Descripci´on Informaci´on de datos compartidos y finalidad con la que se realiza. Entrada Select: Dato y prop´osito con el que se comparte la informaci´on. Servicio: Google Salida esperada Acorde´on desplegable con los datos y finalidad de Google, clasificado por el dato compartido. Salida obtenida Salida esperada. Tabla 8.5: P-05: Dato compartido y prop´osito. 8.1. PRUEBAS DE FUNCIONAMIENTO GENERAL 87 Los casos de prueba de las tablas 8.6 a 8.15 se corresponden con pruebas de filtrado de la informaci´on en base a los resultados de una b´usqueda. P-06 Filtrar por una tecnolog´ıa de seguimiento. Descripci´on Filtrar las categor´ıas de seguimiento obtenidas para un servicio. Entrada Categor´ıa: Collect. Servicio: Yahoo!. Salida esperada Listado con todas las categor´ıas de seguimiento de Yahoo! que incluyen la palabra “Collect”. Salida obtenida Salida esperada. Tabla 8.6: P-06: Filtrar por una tecnolog´ıa de seguimiento. P-07 Filtrar los datos de informaci´on recogidos. Descripci´on Filtrar los datos de primeras partes que son recogidos por la organizaci´on. Entrada Dato: User. Servicio: Google. Salida esperada Acorde´on desplegable de los datos recogidos por Google que contienen la palabra “User”, junto con su finalidad. Salida obtenida Salida esperada. Tabla 8.7: P-07: Filtrar los datos de informaci´on recogidos. P-08 Filtrar la finalidad de la informaci´on recogida. Descripci´on Filtrar la finalidad con la que los datos de primeras partes son recogidos por la organizaci´on. Entrada Dato: Advert. Servicio: Google. Salida esperada Acorde´on desplegable de las finalidades de datos recogidos por Google que contienen la palabra “Advert”, junto con su dato. Salida obtenida Salida esperada. Tabla 8.8: P-08: Filtrar la finalidad de la informaci´on recogida. P-09 Filtrar por el dato y finalidad de la informaci´on recogida. Descripci´on Filtrar el dato y la finalidad con la que los datos de primeras partes son recogidos por la organizaci´on. Entrada Dato: Personal. Finalidad: Ad. Servicio: Yahoo!. Salida esperada Acorde´on desplegable de los datos y finalidades de datos recogidos por Yahoo!, que contienen las palabras “Personal” y “Ad” respectivamente. Salida obtenida Salida esperada. Tabla 8.9: P-09: Filtrar por el dato y finalidad de la informaci´on recogida. 88 CAP´ ITULO 8. PRUEBAS P-10 Filtrar la organizaci´on compartida. Descripci´on Filtrar las organizaciones y ´ambitos con las que se comparten los datos. Entrada Organizaci´on: Vendors. Servicio: Microsoft. Salida esperada Acorde´on desplegable de las organizaciones o ´ambitos para Microsoft que contienen la palabra “Vendors”, jun- to con su elecci´on. Salida obtenida Salida esperada. Tabla 8.10: P-10: Filtrar la organizaci´on compartida. P-11 Filtrar las elecciones del usuario. Descripci´on Filtrar la elecci´on de la revocaci´on y cesi´on con las organizaciones de la informaci´on. Entrada Elecci´on usuario: Consent. Servicio: Microsoft. Salida esperada Acorde´on desplegable de las organizaciones compartidas o ´ambitos para Microsoft donde la elecci´on de usuario es “Consent”. Salida obtenida Salida esperada. Tabla 8.11: P-11: Filtrar las elecciones del usuario. P-12 Filtrar por organizaci´on y elecciones del usuario. Descripci´on Filtrar la organizaci´on y elecci´on de la revocaci´on y ce- si´on con las organizaciones de la informaci´on. Entrada Organizaci´on: Vendors. Elecci´on usuario: Consent. Servicio: Microsoft. Salida esperada Acorde´on desplegable de las organizaciones o ´ambitos y elecciones para Microsoft, que contienen las palabras “Vendors” y “Consent” respectivamente. Salida obtenida Salida esperada. Tabla 8.12: P-12: Filtrar por organizaci´on y elecciones del usuario. P-13 Filtrar el dato compartido con terceros. Descripci´on Filtrar por los datos que son compartidos con terceras organizaciones o entidades. Entrada Dato: Information. Servicio: Yahoo!. Salida esperada Acorde´on desplegable con los datos que son compartidos con terceras organizaciones por Yahoo! donde el dato filtrado es “Information”, junto con su prop´osito. Salida obtenida Salida esperada. Tabla 8.13: P-13: Filtrar el dato compartido con terceros. 8.1. PRUEBAS DE FUNCIONAMIENTO GENERAL 89 P-14 Filtrar el prop´osito del dato compartido con terceros. Descripci´on Filtrar por los prop´ositos de los datos que son compartidos a terceras organizaciones o entidades. Entrada Dato: Use. Servicio: Yahoo!. Salida esperada Acorde´on desplegable con los datos de terceros, junto con el prop´osito con el que los datos que son compartidos con terceras organizaciones por Yahoo!, donde el prop´osito filtrado es “Use”. Salida obtenida Salida esperada. Tabla 8.14: P-14: Filtrar el prop´osito del dato compartido con terceros. P-15 Filtrar el dato y prop´osito de la informaci´on compartida con terceros. Descripci´on Filtrar por los datos y prop´ositos de los datos que son compartidos a terceras organizaciones o entidades. Entrada Dato: Personal. Prop´osito: Law. Servicio: Microsoft. Salida esperada Acorde´on desplegable con los datos de terceros, junto con el prop´osito con el que los datos que son compartidos con terceras organizaciones por Yahoo!, que contienen las palabras “Personal” y “Law” respectivamente. Salida obtenida Salida esperada. Tabla 8.15: P-15 Filtrar el dato y prop´osito de la informaci´on compartida con terceros. Los casos de prueba de las tablas 8.16 y 8.17 se corresponden con pruebas sobre la descarga de la informaci´on de b´usqueda y filtrada. P-16 Funcionamiento de la descarga. Descripci´on Comprobar el funcionamiento de descarga de informaci´on. Entrada Select: Datos y finalidad por la que la organizaci´on recoge la informaci´on. Servicio: Microsoft. Salida esperada Fichero en la carpeta de descargas con los datos de la b´usqueda de Microsoft en formato CSV. Salida obtenida Salida esperada. Tabla 8.16: P-16: Funcionamiento de la descarga. 96 BIBLIOGRAF´ IA [12] Pablo Mart´ın Guti´errez. Data Warehouse: Marco de calidad. https://e-archivo.uc3m. es/bitstream/handle/10016/16343/PFC_Pablo_Martin_Gutierrez.pdf?sequence=2& isAllowed=y, 2011. [Online; accedido 14 de marzo de 2021]. [13] Philippe Rigaux Marie-Christine Rousset Pierre Senellart Serge Abiteboul, Ioana Manolescu. Web Data Management. http://webdam.inria.fr/Jorge/files/ wdm-data-integration.pdf, 2011. [Online; accedido 14 de marzo de 2021]. [14] Razorman. Extracci´on, fase clave en los procesos ETL. https://www.razorman.net/ noticias-de-informatica/extraccion-fase-clave-en-los-procesos-etl.html, 2014. [Online; accedido 27 de marzo de 2021]. [15] Jerryrun. Scalable Data Warehouse Architecture. https://jerryrun.wordpress.com/ 2018/09/11/chapter-2-scalable-data-warehouse-architecture/, 2018. [Online; accedido 2 de Mayo de 2021]. [16] Springer. Data Warehouse Security. https://link.springer.com/referenceworkentry/ 10.1007%2F978-0-387-39940-9_333, 2009. [Online; accedido 02 de Mayo de 2021]. [17] Microsoft. SQL Server Integration Services. https://docs.microsoft.com/es-es/sql/ integration-services/sql-server-integration-services?redirectedfrom=MSDN& view=sql-server-ver15, 2018. [Online; accedido 27 de mayo de 2021]. [18] Microsoft. Descarga de SQL Server Management Studio (SSMS). https://docs. microsoft.com/es-es/sql/ssms/download-sql-server-management-studio-ssms? view=sql-server-ver15, 2021. [Online; accedido 28 de mayo de 2021]. [19] Digital Guide Ionos. ¿Qu´e es el web scraping? https://www.ionos.es/digitalguide/ paginas-web/desarrollo-web/que-es-el-web-scraping/, 2020. [Online; accedido 30 de marzo de 2021]. [20] ParseHub. A free web scraper that is easy to use. https://www.parsehub.com/what_is_ web_scraping. [Online; accedido 30 de marzo de 2021]. [21] Paola Caro. T´ecnicas para identificar Requisitos Funcionales y No Funcionales. https://sites.google.com/site/metodologiareq/capitulo-ii/ tecnicas-para-identificar-requisitos-funcionales-y-no-funcionales, 2012. [Online; accedido 02 de Mayo de 2021]. [22] Craig Larman. UML y patrones. Una introducci´on al an´alisis y dise˜no orientado a objetos y al proceso unificado. Pearson, 2 edition, 2003. [accedido 02 de mayo de 2021]. [23] zappysys. SSIS Powerpack. https://zappysys.com/products/ssis-powerpack/, 2021. [Online; accedido 27 de marzo de 2021]. [24] brettwooldridge. HikariCP. https://github.com/brettwooldridge/HikariCP, 2021. [Online; accedido 01 de Mayo de 2021]. [25] Microsoft. Agente SQL Server. https://docs.microsoft.com/es-es/sql/ssms/agent/ sql-server-agent?view=sql-server-ver15, 2021. [Online; accedido 16 de junio de 2021]. Ap´endice A Pruebas para el proceso de carga Este ap´endice muestra las pruebas realizadas sobre el software de integraci´on de SQL Server Integration Services, y podemos visualizar su correcto funcionamiento de la implementaci´on de los procesos ETL. El proceso ETL totalmente desarrollado con todo el flujo de datos disponible ser´ıa el representado en la figura A.1, donde podemos visualizar que se ha ejecutado correctamente y sin ning´un error. Figura A.1: Pruebas ETL flujo de datos. No obstante, entrando m´as en detalle en alguna de las tareas de este flujo de datos (figuras A.2 a A.4), podemos ver el n´umero de filas del que se parte en el origen en la extracci´on y finalmente van pasando por la transformaci´on, filtr´andose hasta la carga. En los correspondientes ficheros de salida de error, como ya se indica en las figuras, est´an vac´ıos. La figura A.5 nos permite comprobar la actualizaci´on de la informaci´on de la clasificaci´on de ese servicio. 97 98 AP´ ENDICE A. PRUEBAS PARA EL PROCESO DE CARGA Figura A.2: Pruebas ETL carga Servicio ToS;DR. Figura A.3: Pruebas ETL carga Dato OPP-115. Las pruebas aqu´ı consistir´ıan en comprobar que el proceso se ha realizado correctamente en cada tarea de flujo, no hay errores en los ficheros de salida de error, y que los registros que tiene el fichero origen se corresponden con lo que se ha introducido en la base de datos, ejecutando consultas en el sistema gestor e inspeccionando los or´ıgenes para ver si se corresponden los valores. 99 Figura A.4: Pruebas ETL carga Dato PrivaSeer. Figura A.5: Pruebas ETL actualizaci´on Servicio ToS;DR. 100 AP´ ENDICE A. PRUEBAS PARA EL PROCESO DE CARGA Ap´endice B Copia de seguridad y actualizaci´on Este ap´endice describe todo lo relacionado con la seguridad f´ısica mediante copias de seguridad y actualizaci´on del Data Warehouse. Una de las funcionalidades que dispone el gestor SQL Server Management Studio (SSMS) es el Agente SQL Server [25], que es un servicio de Microsoft que ejecuta tareas administrativas programadas, denominadas trabajos en SQL Server. Con este agente conseguimos planificar tareas que se realicen cada cierto periodo de tiempo. B.1. Copia de seguridad En nuestro caso, podemos programar la realizaci´on autom´atica de copias de seguridad del Data Warehouse creado, independientemente si el administrador lo realiza en un determinado instante. El proceso de copia de seguridad consiste en: 1. Iniciar el Agente de SQL Server. 2. En el directorio trabajos, crear un nuevo trabajo. 3. En Step, definimos un nuevo paso con el script Transact-SQL (T-SQL) de la copia de seguridad a realizar sobre la base de datos. 4. En Schedules, se programa la tarea de pasos definida en el punto anterior para que se ejecute peri´odicamente. Las figuras B.1 y B.2 representan los pasos 3 y 4 anterior, respectivamente. En la primera figura, se muestra la vista general para la configuraci´on del step con un T-SQL del backup de la base de datos utilizada como Warehouse. En la segunda figura, tiene lugar la configuraci´on de toda la programaci´on, donde esta tarea programada es: peri´odica, los lunes cada 2 semanas al mediod´ıa y sin fecha de finalizaci´on de esta tarea programada. 101 102 AP´ ENDICE B. COPIA DE SEGURIDAD Y ACTUALIZACI ´ ON Figura B.1: Tarea copia de seguridad del agente en SSMS. Figura B.2: Programaci´on de la tarea copia de seguridad del agente en SSMS. B.2. Actualizaci´on Es posible programar autom´aticamente el proceso de actualizaci´on del Data Warehouse (ETL), independientemente si lo hacemos nosotros como administrador en un determinado instante. Despu´es de haber cargado el paquete con todos los flujos de datos de los procesos ETL en SSMS mediante la creaci´on de un cat´alogo de SSIS, los nuevos pasos a seguir son: 1. En el directorio trabajos, crear un nuevo trabajo. B.2. ACTUALIZACI ´ ON 103 2. En Step, definimos un nuevo paso para que se ejecute autom´aticamente por el agente. En la figura B.3, el tipo de paquete es de SQL Server Integration Services y se ejecuta con el agente de servicio de SQL Server. El paquete es SSIS Catalog que se ha creado el cat´alogo de SSISDB, al realizar la carga del paquete con todos los componentes del proceso ETL. 3. En Schedules, se programa la tarea de pasos definida en el punto anterior siguiendo la pol´ıtica de actualizaci´on definida. Esta tarea programada es: peri´odica, los lunes cada 2 semanas antes del mediod´ıa (antes de una copia de seguridad) y sin fecha de finalizaci´on de esta tarea programada. Figura B.3: Tarea actualizaci´on del agente en SSMS. Figura B.4: Programaci´on de la tarea actualizaci´on del agente en SSMS. 104 AP´ ENDICE B. COPIA DE SEGURIDAD Y ACTUALIZACI ´ ON Ap´endice C Manual de usuario En este ap´endice se presenta el manual de usuario, donde se explica la funcionalidad que se ha implementado en el sistema, es decir, como realizar determinadas tareas. Figura C.1: P´agina de inicio de la b´usqueda. En la figura C.1 podemos visualizar la pantalla de inicio principal, donde un usuario puede introducir la b´usqueda que desea realizar. En ella, se comprueba si el servicio ha sido analizado y est´a disponible o si se ha introducido algo err´oneo no v´alido. Introduciendo los datos por los que se desea buscar, en nuestro caso obtener informaci´on de los datos y finalidad de primeras partes por la que la organizaci´on recoge la informaci´on para Microsoft y pulsando en buscar, nos aparece un acorde´on desplegable de la figura C.2 clasificado por el dato y su correspondiente finalidad. Tambi´en la fecha de incorporaci´on y el documento de donde se ha recogido esa informaci´on. 105