CRYPTDB: SEGURIDAD EN LAS BASES DE DATOS …

Adrián Abalde Méndez
Grado en Ingeniería de Tecnologías de Telecomunicación
Tutores Francisco Javier González Castaño
Lilian Adkinson Orellana Carmela Troncoso
2015
Autor: Adrián Abalde Méndez
Representante académico: Francisco Javier González Castaño
Curso: 2014/2015
I. Introducción Actualmente, el número de usuarios de la mayoría de sistemas informáticos tiende a crecer muy
rápido. Esto es debido a todas las vías de comunicación disponibles, que facilitan la difusión de nuevas tecnologías. Sin embargo, el hecho de que los usuarios activos de cada sistema aumenten de esta forma, implica que el sistema deberá escalar en concordancia. Por ejemplo, si un nuevo software no se actualiza y añade más equipos cuando sus usuarios sobrepasan el límite de recursos disponibles, no podrá dar soporte a todos los que demanden su servicio y, eventualmente, perderá ingresos.
Sin embargo, estas actualizaciones tan necesarias tienen sus limitaciones. El hecho de mejorar los equipos sobre los que se encuentra desplegado el servicio no es inmediato, ya que generalmente requiere una gran inversión monetaria. Por ello, una tendencia que ha aparecido en los últimos tiempos es la de ofrecer servicios en la nube. Si una compañía necesita una mayor capacidad de procesado en sus sistemas, puede contratar equipos que procesarán sus datos de manera online, en lugar de com- prarlos. Del mismo modo, si otra empresa precisa de un aumento en su capacidad de almacenamiento, es posible obtener espacio directamente en la nube para almacenar sus datos, de modo que no tenga que invertir en nuevos servidores. Este nuevo modelo de negocio se denomina infraestructura como servicio o IaaS (Infraestructure as a Service [21]).
La infraestructura como servicio se caracteriza por el hecho de ofrecer recursos altamente esca- lables bajo demanda, que pueden ser configurados y utilizados instantáneamente tras su contratación. De esta forma, se promueve el desarrollo de software, al ofrecer los recursos de bajo nivel de una forma accesible y económica. La infraestructura como servicio tiene muchas ventajas, pero una de las más destacables es que la compañía que utiliza el servicio no necesitará tener un departamento especializado en el mantenimiento y soporte del módulo, contratarlo es suficiente para trabajar con él.
1
Por otro lado, la IaaS también tiene algunas desventajas. La más importante es el hecho de estar ofreciendo acceso a los contenidos propios a una entidad externa. Puesto que es necesario contratar el servicio a una empresa ajena, esta tendrá también acceso a todo aquello que esté relacionado con sus equipos. Por lo tanto, la contratación de la IaaS requiere un acto de fe de la compañía contratante hacia la parte responsable. Un ejemplo claro de ello se encuentra en DBaaS (Database as a Service [13]), donde lo que se contrata es una base de datos externa. Por norma general, las bases de datos almacenan algún tipo de información sensible, la cual debe estar protegida frente a agentes externos que no estén autorizados a consultarla. Por ello, cuando se contrata una base de datos como servicio, la empresa externa, que podría ser un proveedor no confiable, tendrá también acceso a la base de datos y, como consecuencia, a toda su información. Para solucionar este problema es para lo que para lo que nacen las bases de datos seguras y, en particular, la solución de CrypDB.
Base de datos segura es como se denomina a una base de datos que incorpora sistemas de protec- ción de la información frente a agentes externos no autorizados, como un sistema de credenciales o el cifrado de los datos. Este tipo de bases de datos han ido cobrando importancia en los últimos años, en parte debido a la tendencia descrita anteriormente, de externalizar todos los módulos referentes al software de bajo nivel. Sin embargo, aunque la base de datos se encuentre protegida en estado de reposo, es decir, mientras no sea consultada por ningún usuario o aplicación, por norma general, a la hora de procesar y devolver datos, la información se vuelve vulnerable en algún punto de la comunicación, ya sea durante su procesado en el nodo de la base de datos o durante la propia comunicación. Por ejemplo, para procesar algún tipo de consulta que realice una búsqueda sobre una base de datos cifrada, es necesario descifrar la información almacenada para procesarla, devolver el resultado y, encontrado el objeto deseado, que se vuelva a cifrar. El problema que presentan este tipo de sistemas por tanto, es la existencia de un punto en el que la información se encuentra vulnerable en un entorno inseguro, ya que los datos son descifrados y procesados en un sistema externo. En ese instante, la información podría ser atacada fácilmente por un administrador malicioso o por un atacante externo.
Bajo este contexto aparece CryptDB, un software que actúa de intermediario entre un usuario y su base de datos. Se encarga de cifrar y almacenar la información de tal manera que se pueda seguir operando sobre ella aún estando cifrada. Así, por ejemplo, si una empresa tuviese almacenado todo su contenido en una base de datos en la nube, sería posible consultar y procesar la información en la propia base de datos, sin necesidad de ser descifrada. Únicamente se mostrarían los datos en claro al final de la comunicación, en el sistema local del usuario, un entorno que ya se considera seguro y fiable. De esta forma sería posible externalizar el sistema de almacenamiento de una forma segura, sin tener que confiar ciegamente en el proveedor del mismo.
CryptDB soluciona un problema existente de una forma realmente innovadora, por lo que podría tener futuro en el mercado. Sin embargo, es necesario destacar que este sistema no es un producto final y comercial. Se trata de una implementación de una idea para demostrar que es posible llevarla a cabo de manera práctica y funcional. La motivación principal de este estudio es por tanto analizar CryptDB para comprobar si, efectivamente, la solución real propuesta funciona tan bien como se plantea en su versión teórica.
2
II.1. Estructura del proyecto
El principal objetivo de este proyecto, desarrollado en el centro tecnológico Gradiant, es realizar un estudio de prestaciones de CryptDB. Para llevar a cabo este estudio correctamente, será necesario realizar primero dos tareas. En primer lugar, analizar el funcionamiento de CryptDB, y en segundo lugar, desarrollar una aplicación que trabaje con el mismo. Con estas dos tareas se obtendrá una perspectiva mucho más clara del funcionamiento interno de CryptDB, y de su compatibilidad con aplicaciones externas. Esto posibilitará el desarrollo de otra aplicación, denominada de aquí en adelante batería de pruebas, que realizará las pruebas necesarias para el estudio de prestaciones del sistema, almacenando los resultados. Finalmente, a partir de estos resultados será posible extraer una análisis de las prestaciones de CryptDB.
Los dos subobjetivos principales previos al estudio de rendimiento se estructuran de la siguiente manera:
1. Estudio de CryptDB: la primera fase del proyecto consistió en un análisis de las características de CryptDB, incluyendo su funcionamiento, su arquitectura y los distintos elementos de los que se sirve para llevar a cabo su tarea. Para ello se hizo un estudio de todas las funcionalidades que ofrecía, con el fin de entender correctamente su funcionamiento, y comprobar todos los escenarios que se planteaban en su decripción académica [14]. A continuación, se comenzó el estudio de las partes fundamentales de su código, para comprender su arquitectura y los distintos algoritmos que utiliza. Con todo ello se consiguió una perspectiva mucho más clara del sistema lo que permitió abordar los siguientes objetivos del proyecto. El resultado de todo este estudio se puede consultar en el anexo 2, donde se ofrece tanto una visión general del sistema como un análisis más detallado.
2. Desarrollo de una aplicación de consultas seguras: la segunda fase del proyecto consistió en comprobar el grado de compatibilidad de CryptDB con un programa externo, acercando el estudio a un caso de uso más realista. Dado que no existen aplicaciones de código abierto que trabajen con CryptDB, fue necesario desarrollar una propia. Esta aplicación actúa de interfaz gráfica de CryptDB, y ofrece una experiencia de uso del sistema a nivel de usuario. La imple- mentación y funcionamiento de esta nueva aplicación para gestionar los contenidos de una base de datos segura se puede consultar en la sección III. Por otro lado, el manual de usuario de este programa se encuentra detallado en el anexo 3.
Finalmente, tras alcanzar los dos subobjetivos anteriores, se procedió a realizar el análisis de prestaciones de CryptDB, el objetivo principal de este trabajo. Para ello se desarrolló la batería de pruebas mencionada anteriormente, con el fin de obtener unos datos numéricos acerca del rendimiento del sistema. El siguiente paso fue representar gráficamente todos estos datos, para observar de forma más clara el funcionamiento de CryptDB en los distintos escenarios. Con todo esto se esperaba llegar a una conclusión de si la sobrecarga para trabajar con el sistema es lo suficientemente pequeña para poder integrarlo en un caso real, o si CryptDB es únicamente viable en unos determinados escenarios con tipos de bases de datos concretas. Los resultados de este estudio son descritos en la sección III.
3
II.2. Estructura de la memoria
Este documento está dividido en tres capítulos principales y cuatro anexos. Los capítulos hacen referencia a los objetivos principales de este estudio y, en ellos, se exponen los resultados del mismo. En los anexos se presentan los subobjetivos que, a pesar de no estar presentes como resultados, ya que son secundarios, resultan igualmente imprescindibles para la realización del proyecto.
En la sección III se describen los resultados principales del proyecto, es decir, el funcionamiento de la aplicación desarrollada y los resultados de la comparativa de eficiencia realizada sobre CryptDB. En la última sección, la sección IV, se exponen las conclusiones en base a los resultados obtenidos, finalizando con las posibles líneas futuras que podría tener CryptDB.
Al final de la memoria se pueden encontrar los anexos. El anexo número 1 comprende un estado del arte donde se introducen los conceptos básicos para este estudio, como lo son las bases de datos, la seguridad informática y la combinación de ambos elementos. En el anexo número 2 se recogen los resultados del subobjetivo número 1, el estudio de CryptDB. Inicialmente se introduce la idea principal de CryptDB para, a continuación, describir desde un punto de vista general su funcionamiento e implementación. Para ofrecer un estudio con más detalle, el ultimo apartado profundiza en las partes más técnicas del sistema como la arquitectura, la robustez del sistema o los algoritmos de cifrado que utiliza. Por último, en el anexos 3 se incluye un manual de usuario de la aplicación de consultas seguras desarrollada, resultado del subobjetivo número 2. En este manual se muestran las distintas pantallas de las que consta este programa y las funcionalidades que ofrece.
III. Resultados En este capítulo se describen los resultados obtenidos en este proyecto. Para ello, el capítulo está
dividido en dos partes principales, donde se tratan los objetivos de la aplicación y de la comparativa de eficiencia respectivamente.
En el primer fragmento de este capítulo se describe la implementación de la aplicación de consultas seguras. En él se enumeran los principales casos de uso de este programa y, posteriormente, se muestra una representación gráfica de su estructura con una breve explicación de su funcionamiento interno.
En la segunda parte de este capítulo se detalla el experimento de la comparativa de eficiencia. Inicialmente se describen las pruebas propuestas, es decir, como se organizó la realización de dicho experimento para obtener unos resultados coherentes acerca de las prestaciones del sistema. A continuación se encuentran los apartados donde se exponen los distintos resultados obtenidos y sus implicaciones.
III.1. Aplicación de consultas seguras
Para comprobar el funcionamiento de CryptDB en un escenario más realista, era necesario probar el sistema en un escenario que implicase su integración con una aplicación. Sin embargo, en la actualidad no existe ninguna aplicación que trabaje explícitamente de esta manera. Por ello, se optó por desarrollar una aplicación que utilizase el sistema para realizar consultas seguras a una base de datos cifrada. El lenguaje escogido para el desarrollo de este software fue el lenguaje Java, principalmente por las facilidades que ofrece para la comunicación con bases de datos.
Los usos principales de la aplicación desarrollada son dos:
4
a) Acceso indirecto
La aplicación ofrece una interfaz gráfica para simplificar la utilización de CryptDB. Esto significa que un usuario, utilizando esta aplicación, podría crear una base de datos cifrada y realizar consultas sobre sus datos a través del sistema seguro. Este proceso es totalmente transparente, es decir, el usuario no es consciente en ningún momento de que toda la información está siendo cifrada. Este caso de uso sería muy similar a la utilización de CryptDB en un sistema real.
b) Acceso directo
Puesto que esta aplicación tiene fines meramente académicos, se decidió añadir un módulo de- mostrativo. Este módulo permite consultar directamente la base de datos cifrada, lo que significa que el resultado de cualquier consulta será el propio texto cifrado. De esta forma, se facilita la comprobación del funcionamiento del sistema al poder consultar las tablas cifradas en cualquier momento. Lo que se busca con este añadido es, principalmente, ofrecer el acceso a la base de datos MySQL como lo haría un posible administrador malicioso y descubrir como, efectivamente, toda la información está cifrada y, por lo tanto, protegida.
La representación gráfica de estos dos casos de uso se muestra en la figura III.1. En ella las dos posibles opciones son denominadas como acceso directo y acceso indirecto.
Figura III.1: Esquema gráfico de los casos de uso de la aplicación. a) Acceso indirecto. b) Acceso directo.
Para la conexión de la aplicación con CryptDB y con MySQL se utilizó la librería de Java JDBC1, Java Data Base Connectivity. Esta librería ofrece una conexión independiente entre el lenguaje Java y un rango de bases de datos muy amplio, proporcionando llamadas a nivel de API. Para hacer posible los dos accesos distintos a la base de datos, es necesario que el servidor MySQL se encuentre en un puerto del equipo y el proxy de CryptDB en otro distinto (en el arranque de cada plataforma se especifica el valor de puerto deseado). Cuando se arranca el proxy es necesario especificar la dirección donde está localizado el servidor MySQL. De esta forma en la aplicación serán creadas dos conexiones distintas, a cada dirección, y se utilizará una u otra según la acción requerida por el usuario.
Como se puede observar en la figura anterior, los datos se cifran en el bloque de CryptDB. Por defecto, los datos insertados por primera vez se cifrarán con el algoritmo RND, de mayor seguridad. Sin embargo, a medida que se vayan realizando consultas sucesivas sobre las tablas, la capa de cifrado exterior de los datos se irá actualizando dinámicamente (ver anexo 2). La clave con la que son cifrados es la master key de CryptDB. Un valor de clave constante y almacenado en el propio sistema, al que
solo tiene acceso CryptDB. De este modo, cuando se realicen consultas mediante acceso indirecto, CryptDB procesará las consultas y las cifrará con esta clave, almacenándolas posteriormente en la base de datos MySQL. De la misma forma, en la acción inversa, consultar, CryptDB recibirá datos cifrados y, mediante esta clave y los distintos algoritmos de los que hace uso, devolverá el texto en claro al bloque de aplicación.
El manual de usuario referente a esta aplicación se encuentra en el anexo número 3. Este anexo detalla como hacer uso de las distintas ventanas que tiene el programa y las funcionalidades que ofrece cada una.
III.2. Comparativa de eficiencia
III.2.1. Descripción del experimento
La calidad del servicio ofrecido por una base de datos se mide, generalmente, por dos factores principales: el tamaño y los tiempos de ejecución. El principal objetivo de una base de datos es el de almacenar información, por ello una de las características en las que primero se fijan los posibles usuarios es en su eficiencia a la hora de almacenar datos. Es importante que las estructuras utilizadas por la base de datos sean eficientes, ya que de ello dependerá cuánto ocupen los datos a la hora de almacenarlos. Una base de datos que no haga uso de estructuras eficientes no es una buena opción para aquellos sistemas que puedan trabajar con grandes volúmenes de información y la capacidad de almacenamiento pueda llegar a estar limitada.
De la misma forma, el otro factor relevante de las bases de datos son los tiempos de ejecución. Es importante que las consultas entre grandes volúmenes de información sean rápidas para ofrecer un servicio fluido de cara a los usuarios. Una base de datos que no tenga un sistema de consulta rápido, ofrecerá una calidad de servicio muy baja en los momentos en los que se requiera algún tipo de recuperación de información.
Pueden existir bases de datos que se especialicen en estructuras muy eficientes en cuanto a ta- maño, para ocupar poco espacio, o bases de datos donde la capacidad de almacenamiento no sea tan importante, y cuya mayor prioridad sea la velocidad en las consultas. Por norma general, los sistemas gestores de bases de datos buscan un equilibrio entre ambos factores, para que su base de datos trabaje de forma eficiente en la mayoría de escenarios posibles.
En esta comparativa de eficiencia se busca analizar ambos factores de CryptDB, tamaño y velocidad de ejecución, para poder establecer cuantitativamente lo bueno, o malo, que puede llegar a ser este sistema.
En este caso, para el análisis de CryptDB se utiliza la base de datos MySQL como referencia. La idea es realizar ciertas acciones sobre la base de datos MySQL y, posteriormente, realizar esas mismas acciones sobre CryptDB. El tiempo de ejecución de cada una de las acciones será almacenado, lo que permitirá, una vez finalizadas las pruebas, comparar los tiempos de una plataforma con los de la otra. Intuitivamente los tiempos de CryptDB serán, en general, mucho mayores que los de MySQL, pero el objetivo es determinar cuantitativamente esa diferencia.
El equipo sobre el que se llevó a cabo todo el análisis es un Optiplex 780, con un procesador Intel Core Duo de 2.93 GHz, 4 GB de memoria RAM y el sistema operativo Ubuntu versión 12.04 de 64 bits.
La base de datos utilizada por ambos sistemas es la misma y su tamaño es contabilizado en forma de tuplas, o filas, por tabla. El modelo lógico de esta base de datos de pruebas es el de una base de datos
6
de deportes constituida por ocho tablas (Deportes, Tipos, Disciplinas, Equipos, Jugadores, Entrena- dores y Patrocinadores) que contienen atributos de tipos variados. El diagrama entidad-asociación de esta base de datos se muestra en la figura III.2.
Los tamaños empleados de esta base de datos son: 100, 300, 500, 700, 1000, 3000, 5000, 7000, 10000, 15000, 30000 tuplas por tabla. Por lo tanto, la base de datos utilizada de mayor tamaño está constituida en total por 30000 · 8 = 240000 tuplas y ocupa un total de 40 MB en MySQL y alrededor de 356 MB en CryptDB. Y, por el contrario, la de menor tamaño tiene 100 · 8 = 800 tuplas y ocupa 300 KB en MySQL y sobre 32 MB utilizando CryptDB.
Para crear estas bases de datos se realizó una batería de pruebas, desarrollada en lenguaje Java, que genera de forma aleatoria tantas consultas de tipo INSERT como tuplas tuviese la base de datos que se desease generar, y los almacena en un archivo de texto. Para no alterar lo que sería el contexto real de la información, los datos generados por el programa no son totalmente aleatorios. Por ejemplo, las fechas tienen un límite numérico tanto inferior como superior, o los nombres se forman a partir de palabras preestablecidas. De esta forma, se pueden generar bases de datos de manera pseudoaleatoria sin perder la coherencia de su información.
Figura III.2: Diagrama entidad-asociación de la base de datos utilizada en la comparativa de eficiencia de CryptDB.
7
El banco de consultas utilizado se puede dividir en grupos. Esta clasificación se rige por dos factores principales: en primer lugar, el tipo de datos a tratar en la consulta, es decir, los datos que serán devueltos como resultado y sobre los que se realizarán las operaciones (INTEGER, DECIMAL, TEXT o VARCHAR) y, en segundo lugar, el nivel de complejidad de la consulta (básica, simple o compleja). Las consultas básicas son aquellas que no realizan ningún tipo de operación, únicamente consultan un dato. Las consultas simples, al contrario que las básicas, realizan una de las operaciones soportadas por CryptDB (=, <, >, +). Por último, las consultas complejas, aparte de realizar alguna operación de las anteriores, lleva a cabo un JOIN.
El procedimiento es ejecutar 1000 consultas de cada grupo tipo-complejidad y almacenar sus tiempos de ejecución. Posteriormente, para obtener un resultado lo más ajustado posible, se calculan las medias y las varianzas de dichas consultas. De este modo, teniendo la varianza, también se tiene la desviación típica y, por lo tanto, se puede observar cuanto varían los resultados en torno a su valor medio, es decir, su precisión.
III.2.2. Resultados
En este apartado se describen los resultados obtenidos a partir de la batería de pruebas. Se divide principalmente en cinco comparativas principales, que analizan el sistema desde distintos puntos de vista. En primer lugar, se realiza una comparativa entre capas de cifrado. Las consultas de la batería de pruebas realizan operaciones distintas, por lo que también usan distintas capas. De este modo, se agruparán las consultas por capas, y será posible comparar la eficiencia entre las mismas.
En segundo lugar, se encuentra la comparativa de complejidad. En este caso las consultas se agru- parán por tipo de dato y, de esta forma, serán comparadas por sus distintos tipos de dificultad. Por ejemplo, agrupando las consultas por el tipo INT, se compararán las consultas INT BÁSICO, INT SIMPLE e INT COMPLEJO.
En tercer lugar, se presenta una comparativa con los tiempos de las primeras consultas. Se compará la batería de pruebas de 1000 consultas de un determinado tipo con el tiempo que tardó su primera consulta. Con esta analítica se pretende observar la importancia del ajuste dinámico de las capas.
En cuarto lugar, una vez analizada la eficiencia del sistema desde distintos puntos de vista, es necesario compararla con una implementación real no cifrada, como es MySQL. De esta forma será posible observar la sobrecarga de los tiempos de ejecución al utilizar CryptDB. Para ello se presentarán los tiempos medios de cada consulta realizada sobre CryptDB frente a sus homónimos en MySQL.
Por último, se lleva a cabo una comparativa de tamaños. En este caso se pretende analizar la sobrecarga de tamaño que implica el uso de CryptDB. Para ello se comparan los tamaños de las bases de datos MySQL con los tamaños de las bases de datos generadas a través de CryptDB. De esta forma, se podrá observar la capacidad de almacenamiento extra que requeriría utilizar el sistema de seguridad.
COMPARATIVA ENTRE CAPAS
En CryptDB existen cinco capas de cifrado distintas, donde cada una soporta una operación dife- rente, tal y como se muestra en la tabla I. La capa RND es la que aporta una mayor seguridad dentro del sistema, pero no soporta ningún tipo de operación. Por otro lado, la capa HOM es la más segura de las capas que soportan operaciones, pero solo realiza sumas y con una eficiencia muy baja. En el caso de OPE, se revela el orden de sus valores de entrada para dar un soporte eficiente a las operaciones de comparación, pero ello también implica filtrar más información que HOM. Para soportar igualdades, DET ha de conservar el formato de la entrada, sin ningún tipo de procesado aleatorio, lo que equivale a
8
un nivel de seguridad menor que el de las dos capas anteriores. Por último, la capa JOIN y OPE-JOIN ofrece la posibilidad de realizar operaciones JOIN sobre los textos cifrados. Ya que existen dos tipos de JOIN, por igualdad y por comparación, sus respectivos niveles de seguridad son similares a las capas que soportan estas operaciones, DET y OPE.
Tabla I: Capas de cifrado de CryptDB.
RND Sin operaciones DET =
JOIN y OPE-JOIN JOIN
El objetivo de este análisis es representar los tiempos de ejecución de consultas que usan distintas capas y que tienen una complejidad similar. De esta forma es posible observar cuáles son las capas más rápidas y más lentas, y sobre qué tipos de dato alcanzan el mejor rendimiento.
RND. Para analizar esta capa se representan los tiempos de ejecución de las consultas de complejidad básica que, al no tener ningún tipo de operación en su predicado, hacen uso de esta capa. La representación gráfica de estas consultas se muestra en la figura III.3.
Figura III.3: Tiempos medios y desviación de las consultas que utilizan la capa RND.
Se puede observar como los tiempos de las consultas presentan un incremento creciente, siguiendo un crecimiento casi lineal. Entre los valores de bases de datos de 5000 y 7000 tuplas/tabla, los tiempos del tipo VARCHAR bajan ligeramente. Esto se debe a la caché de con-
9
sultas que almacena MySQL2. MySQL almacena en su memoria temporal consultas realizadas junto con su resultado. De esta forma, si en un tiempo determinado recibe una consulta similar, puede devolver el resultado almacenado sin necesidad de su procesado. El tipo VARCHAR corresponde al campo «Nacionalidad» en la base de datos «Deportes» y, en la aplicación gene- radora de datos, los valores posibles para este campo solo varían entre nueve posibles, es decir, tiene un espacio de valores pequeño. Por ello, en esta consulta de tipo VARCHAR Básico, donde solo se consulta la nacionalidad, es donde más eficaz será la cache con su reducido rango de valores, de modo que, cuanto mayor sea la base de datos, mayor repercutirá en el promedio de las consultas.
DET. Para analizar esta capa se representan las consultas DECIMAL SIMPLE y VARCHAR SIMPLE, las cuales tienen una operación de igualdad en su predicado. La representación gráfica de estas consultas se muestra en la figura III.4.
De nuevo, las consultas sobre la capa DET que utilizan los tipos VARCHAR son las más eficientes. Sin embargo, en este caso la consulta VARCHAR presenta una desviación mucho mayor que el anterior, por lo que los resultados de cada consulta podrían alejarse del promedio esperado.
Dado que el tipo DECIMAL es un tipo numérico complejo de precisión matemática, sus textos de cifrado serán mayores que los que generará el tipo de texto simple VARCHAR, que además, en esta base de datos, tiene su longitud limitada a 3 caracteres. Por ello los tiempos de consulta del tipo DECIMAL son mayores que los de VARCHAR, ya que las computaciones de igualdad serán más veloces cuanto menor sea el texto cifrado resultante.
Figura III.4: Tiempos medios y desviación de las consultas que utilizan la capa DET.
OPE. Para este caso se han utilizado las consultas INT SIMPLE y TEXT SIMPLE, ya que ambas realizan una operación de comparación. La representación gráfica de estas consultas se muestra en la figura III.5.
2https://dev.mysql.com/doc/refman/5.1/en/query-cache.html
10
En la capa OPE el tipo de dato que presenta un peor rendimiento vuelve a ser el TEXT, llegando a tardar casi cuatro veces más que el tipo entero. Sin embargo, las consultas del tipo entero tienen una desviación típica muy elevada, llegando a doblar su valor. Esto indica que la estimación del promedio para el tipo entero simple no es exacta. No obstante, aún en el peor de los casos, el entero simple sigue tardando menos que la consulta con datos de tipo texto en su caso óptimo. Las grandes varianzas en estos experimentos se deben a que las bases de datos y las consultas son generadas de forma aleatoria. Por lo tanto, pueden darse ocasiones en las que se genere una base de datos que contenga o muchos datos coincidentes con la consulta, o muy pocos, lo que provoca aumentos o disminuciones de tiempo respectivamente.
Figura III.5: Tiempos medios y desviación de las consultas que utilizan la capa OPE.
HOM. Esta capa no era utilizada por ninguna de las consultas planteadas en la batería de pruebas, por ello fue necesario añadir posteriormente otro grupo de consultas que realizasen espe- cíficamente una operación de suma. Estas consultas tienen una complejidad de nivel simple, por lo que sus dimensiones deberan ser comparadas con otras consultas de nivel simple. La representación gráfica de su rendimiento se muestra en la figura III.6.
Figura III.6: Tiempos medios y desviación de las consultas que utilizan la capa HOM.
11
Esta gráfica tiene una forma mucho más irregular que las anteriores, con pequeñas subidas y bajadas entre cada valor. Sin embargo, es algo esperado, dadas las grandes variaciones que presenta, de ordenes similares a las del tipo INT SIMPLE del análisis anterior. Estas variaciones son, de nuevo, debidas a la naturaleza aleatoria de la base de datos.
JOIN. Para representar el rendimiento de estas capas se utilizaron las consultas de nivel complejo, ya que todas realizan una operación de JOIN en su predicado. La representación gráfica del rendimiento de la capa JOIN se muestra en la figura III.7.
En esta capa el valor que presenta un mejor rendimiento es el de tipo entero. Podría llevar a confusión el hecho de que las consultas sobre VARCHAR están también muy cerca del valor medio de las de tipo entero. Sin embargo, estas consultas muestran una varianza realmente grande, que puede llegar a ser de cinco veces el valor medio, situándose por encima del segundo tipo más lento, el tipo DECIMAL. Esta gran varianza significa que el valor medio no es una representación fiable, y el rendimiento medio en un caso real podría ser peor al representado.
Figura III.7: Tiempos medios y y desviación de las consultas que utilizan la capa JOIN.
Como conclusión de esta comparativa de capas, se obtienen los tipos de dato sobre los que cada capa presenta un mejor rendimiento. El tipo TEXT ofrece unas prestaciones muy bajas en todas las capas, de lo que se deduce que uno de los peores escenarios donde utilizar CryptDB sería una base de datos donde se almacenasen grandes volúmenes de datos de tipo TEXT. Por el contrario, las cadenas de caracteres de longitud limitada, como es el tipo VARCHAR en este caso, tienen unos tiempos de procesado realmente bajos en general, pero también son los que presentan un factor de error mayor, por lo que en una implementación real, los resultados podrían cambiar mucho del valor teórico esperado. A pesar de ello, aún asumiendo el peor caso, sus tiempos se encuentran dentro de un rango aceptable comparado con los promedios del resto de tipos.
Entre la capa RND y las capas OPE y DET, se puede observar como existe una mejora en cuanto a rendimiento en las consultas, ya que los tiempos de OPE y DET son menores en INT, DECIMAL y VARCHAR. No olvidar que, a pesar de estar ganando rendimiento por un lado, se está perdiendo
12
seguridad por el otro, ya que OPE y DET tienen un nivel de seguridad menor que RND. Por el contrario, el tipo TEXT mantiene las mismas prestaciones entre RND y OPE. Esto se puede interpretar de dos formas distintas: o la capa TEXT tiene un rendimiento tan bueno en RND que se mantiene al mismo nivel al cambiar a OPE, o que la capa TEXT tiene un rendimiento tan malo en OPE que es igual al de RND. Esta igualdad entre el rendimiento de RND y OPE, sería beneficiosa si CryptDB se fuese a utilizar con una base de datos que no realizase operaciones sobre el texto, ya que se mantendría siempre la capa de máxima seguridad sin perder prestaciones.
Por otra parte, HOM presenta unas prestaciones de dimensiones muy similares al resto de capas funcionales, aún teniendo un nivel de seguridad superior. Por lo que utilizando operaciones de suma se está ganando en seguridad, sin perder rendimiento respecto a otras operaciones de igualdad o de comparación.
En último lugar, la capa JOIN se muestra como la capa más lenta de todas, donde las consultas tardan más tiempo en ser ejecutadas para los tipos DECIMAL y TEXT. Especialmente para este último, donde el tiempo de consulta llega a doblarse en su último valor respecto a las otras consultas. Esto es debido a la complejidad de llevar a cabo una operación JOIN sobre texto cifrado. Por otra parte parece tener un procesado eficiente para tipos de datos cortos como INT y VARCHAR, donde su rendimiento llega a ser mejor que en la capa RND.
COMPARATIVA ENTRE NIVELES DE COMPLEJIDAD
El ciclo de vida de una consulta se divide en subtareas. De la velocidad con la que se ejecuten esas tareas dependerá el tiempo que tarde la consulta en realizarse. Por ello, por norma general, la complejidad de una consulta aumenta el tiempo que esta tardará en llevarse a cabo, ya que más complejidad implica un mayor número de tareas a realizar [19].
El objetivo de esta comparativa es comprobar ese grado de correlación existente entre el tiempo de ejecución de una consulta y la complejidad de la misma, utilizando como escenario CryptDB. De esta forma, se podrá estudiar si la complejidad de las consultas es un factor importante, a tener en cuenta a la hora de buscar los escenarios ideales para este sitema, o si, por el contrario, no tiene un impacto relevante en el rendimiento. Para ello se representarán de manera gráfica todas las consultas agrupadas por tipo, es decir, INT, DECIMAL, TEXT y VARCHAR.
En primer lugar se analizan los datos de tipo INT. Para ello, la representación de sus valores promedio junto con su desviación, que se presenta en la figura III.8.
En la representación gráfica de este experimento, no está presente la idea expuesta al inicio del apartado: a mayor complejidad, mayor tiempo de ejecución por consulta, ya que las consultas más sencillas son las que más tiempo tardan. Esto se debe a que en estas pruebas también se tiene en cuenta el tiempo que tardan los datos en regresar al usuario. En MySQL, una vez la consulta se lleva a cabo, los datos que han sido encontrados son devueltos al usuario directamente, sin ningún tipo de procesado, es inmediato, y solo depende de la capacidad del canal de comunicación. Por el contrario, en CryptDB, es preciso incluir en el tiempo de la consulta la tarea de descifrado, puesto que los datos que se devuelvan desde MySQL todavía están cifrados. Por lo tanto, en estas consultas de prueba realizadas se puede dividir su tiempo en dos acciones principales: el hecho de llevar a cabo la consulta, es decir, obtener los resultados que encajen con las condiciones del predicado, y la acción de descifrar esos resultados.
En este caso en concreto, las consultas sobre tipos INT de complejidad básica obtienen como resultado una cantidad de datos mucho mayor que las consultas más complejas que, al tener cualquier tipo de condición, son más restrictivas. Puede que la realización de la consulta sea rápida, ya que al
13
consultar una tabla completa, el motor MySQL no tiene que realizar ningún tipo de procesado de los datos, tan solo debe devolver la tabla indicada. Sin embargo, esa tabla se encuentra cifrada, todavía es necesario descifrarla con CryptDB. Por ello, cuanto mayor es el tamaño de las tablas de las bases de datos, más se disparan los tiempos de ejecución de las consultas que devuelven grandes cantidades de información. El ligero incremento que se puede observar en la gráfica de INT COMPLEJO se debe a la naturaleza pseudoaleatoria de la base de datos y de las consultas. Hubo un gran número de coincidencias, lo que aumentó ligeramente los tiempos de consulta.
Figura III.8: Tiempos medios y desviación de las consultas INT con distintos grados de complejidad.
También es influyente el análisis de la capa JOIN realizado anteriormente. En ella se expuso el rendimiento de la capa JOIN para los distintos tipos de datos y, se podía observar como los mejores rendimientos se alcanzaban para los datos pequeños como los INT y los VARCHAR. Por ello, sucede el mismo fenómeno con los tipos VARCHAR, ya que el tiempo de realización de la consulta se vuelve despreciable frente a los tiempos de descifrado del resultado. La representación gráfica del tipo VAR- CHAR se muestra en la figura III.9. La causa del pico que se puede apreciar en esta gráfica, situado en 5000 tuplas/tabla, está descrita en el apartado de comparativa de capas.
Figura III.9: Tiempos medios y desviación de las consultas VARCHAR con distintos grados de complejidad.
14
Ambas gráficas presentan desviaciones muy elevadas en las consultas más complejas, especialmente la de tipo VARCHAR. De lo que se deduce que en estos dos tipos tiene mayor impacto de rendimiento la acción de descifrar que la acción de consultar. Los tipos INT y los tipos VARCHAR se consultan muy rápido, como se observa en los tiempos de sus consultas más complejas, pero en donde más se retrasan es en la tarea de descifrado de los datos. Por el contrario, como se muestra en las dos siguientes figuras correspondientes a los tipos DECIMAL y TEXT (figuras III.10 y III.11 respectivamente), este hecho no sucede en tipos de dato más complejos.
En estos dos casos se puede observar como la propia ejecución de la consulta si que tiene un gran impacto en el tiempo estimado y, por ello, en ambas gráficas, la consulta que tarda más en ejecutarse es la de nivel complejo. El ligero incremento que se puede observar en la gráfica de VARCHAR COMPLEJO se debe a la naturaleza pseudoaleatoria de la base de datos y de las consultas. Hubo un gran número de coincidencias, lo que aumentó ligeramente los tiempos de consulta.
Figura III.10: Tiempos medios y desviación de las consultas DECIMAL con distintos grados de complejidad.
Figura III.11: Tiempos medios y desviación de las consultas TEXT con distintos grados de complejidad.
15
La conclusión de este análisis es que el tiempo de devolución de los datos, donde se encuentra la acción de descifrar, no puede ser despreciado frente al de ejecución de la consulta. En los tipos más sencillos, como el INT y el VARCHAR, las consultas se realizan a una gran velocidad pero, por el contrario, es el descifrado lo que añade una mayor sobrecarga temporal. Por otro lado, en los tipos mas complejos como DECIMAL y TEXT, la complejidad de la consulta tiene una influencia mucho mayor en el tiempo total y, por ello, son las consultas de alta complejidad las que experimentan los mayores retrasos.
COMPARATIVA CON PRIMERAS CONSULTAS
Como se explica en el apartado 2.1.2, CryptDB realiza un ajustado dinámico de las capas de cifrado en tiempo de ejecución. El objetivo de este apartado es comprobar la importancia de ese ajuste dinámico.
Para llevar a cabo este experimento se almacenó el tiempo de ejecución de la primera consulta de cada grupo de 1000 consultas de prueba. De esta forma, se tiene una estimación de las magnitudes de los tiempos de estas primeras consultas. Este estudio solo se realiza sobre consultas de nivel de complejidad simples y complejas, ya que las consultas de nivel básico no tienen ninguna operación en su predicado y, por lo tanto, no ajustan ningún tipo de capa.
SIMPLES. Se muestra en la figura III.12 la representación gráfica de todas las consultas de nivel simple, junto con sus respectiva primera consulta. En este caso la capa es ajustada desde RND a OPE o DET, según la operación que sea precisa.
Figura III.12: Tiempos de la primera consulta y de las posteriores. Complejidad: simples.
La representación de los datos cuadra con el resultado esperado: las primeras consultas son más lentas que sus consultas sobre capas ya ajustadas. Se puede observar como las primeras consultas que menos tardan son las correspondientes a tipos más primitivos como INT y VARCHAR, y aquellas más lentas trabajan con tipos de datos más complejos, como TEXT y DECIMAL. El orden de las primeras consultas es exactamente el mismo que el de las consultas con las capas ya ajustadas, con la diferencia de que la consulta ya ajustada se lleva a cabo con mayor rapidez.
16
COMPLEJAS. El siguiente experimento se realizó con las consultas complejas, que necesitan profundizar más en las capas y llegar hasta el nivel de JOIN. La representación gráfica se muestra en la figura III.13.
En esta ocasión los tiempos de ajuste aumentan mucho más que en el experimento anterior, debido a que el ajuste tiene que profundizar una capa más abajo (figura 2.2). El orden de las consultas es similar al anterior, con las consultas sobre datos primitivos como las más veloces, seguidas por los tipos de dato más complejos DECIMAL y TEXT.
La conclusión de estas dos comparativas es que el cifrado de capas ajustables tiene, efectivamente, un impacto positivo en el rendimiento del sistema. Por ejemplo, en el peor caso (consultando sobre datos de tipo TEXT), las consultas complejas tardarían casi 12 segundos, mientras que con el cifrado ajustable tardan solo 4, tres veces menos. Esto equivale a decir que por cada consulta realizada en un sistema sin cifrado ajustable, otro que si tuviese una implementación dinámica realizaría tres. Por lo tanto, una vez estuviese la mayoría de la base de datos ajustada a la capa adecuada, el sistema dinámico trabajaría tres veces más rápido que el no dinámico, lo que implica una mejora de prestaciones importante.
Figura III.13: Tiempos de la primera consulta y de las posteriores. Complejidad: complejas.
COMPARATIVA ENTRE CryptDB Y MySQL
El objetivo de este apartado es observar cuanta sobrecarga temporal añadiría CryptDB, con respecto a MySQL, en el uso de una base de datos. Para ello, se ejecutó exactamente la misma batería de pruebas en MySQL y en CryptDB, utilizando también la misma base de datos, almacenando todos sus resultados para poder representarlos. Intuitivamente, se espera que los tiempos de CryptDB sean mayores que los de MySQL, ya que el acceso directo al DBMS de MySQL no tiene ningún tipo de sobrecarga adicional. En este apartado se mostrarán cuatro casos diferentes. En cada caso, se compararán las tres consultas de cada tipo de dato con sus homónimas realizadas en MySQL.
INT. El primer caso corresponde a datos de tipo entero. Las representaciones gráficas de las consultas se muestran en la figura III.14. Se puede observar como las tres consultas sobre enteros
17
de CryptDB, tardan un tiempo mucho mayor que esas mismas consultas realizadas directamente sobre MySQL. Las consultas sobre la plataforma segura rondan entre los 250 y los 1300 ms, mientras que las consultas sobre MySQL se encuentran en todo momento varios ordenes de magnitud por debajo.
A partir de esta gráfica se puede extraer una estimación porcentual de cuanta sobre carga im- plicaría utilizar CryptDB sobre datos de tipo entero. Asumiendo la base de datos más grande posible, en este caso 30000 tuplas/tabla, y tomando como valores de cada plataforma la mitad del punto máximo, 650 ms para CryptDB y 16 ms para MySQL, la sobrecarga temporal sería 40 veces superior, es decir, un 4000 %. Por otro lado, realizando los mismos cálculos para una base de datos menor, utilizando los valores de 1.3 ms para MySQL y 48.5 ms para CryptDB, la sobrecarga resultante se encuentra en torno al 3700 %. De ambos valores se deduce que la sobrecarga en este tipo de dato presenta un comportamiento casi constante, que aumenta ligeramente y de forma progresiva con el tamaño de la base de datos.
Figura III.14: Tiempos de las consultas de tipo INT en CryptDB y en MySQL.
DECIMAL. En este caso, se comparan las tres consultas de distinta complejidad pertenecientes al tipo DECIMAL, de nuevo ejecutadas sobre distintas plataformas. La interpretación gráfica de estos resultados se presenta en la figura III.15.
Se puede observar en esta comparación del tipo DECIMAL, como los resultados son muy similares a los del caso de estudio anterior, el tipo INT. Al igual que antes, las gráficas referentes a los valores de CryptDB muestran unos tiempos muy por encima de los de MySQL. A pesar de ello, en esta ocasión, la consulta de nivel complejo en MySQL llegó a alcanzar los 230 ms.
Al igual que en el experimento anterior, se puede estimar un porcentaje sobre la sobrecarga temporal que causa CryptDB. En primer lugar, sobre la base de datos de mayor tamaño (30000 tuplas/tabla), asumiendo como valor para MySQL 115 ms, y para CryptDB 940 ms, el valor porcentual tendría un valor alrededor de un 800 %. Por el contrario, el cálculo sobre la base de datos de 1000 tuplas/tabla, realizado con los valores de 2 ms para MySQL y 73 ms para CryptDB, da como resultado un porcentaje de sobrecarga del 3650 %. En este caso se puede
18
apreciar como la sobrecarga se reduce cuanto mayor es la base de datos. Esto no se debe a que los tiempos de CryptDB sean mejores, se debe a que las consultas DECIMAL de mayor complejidad tardan mucho más en ejecutarse sobre MySQL y ello causa que la diferencia con CryptDB sea menor. Este fenómeno se puede observar en el aumento final en la gráfica de la consulta de DECIMAL COMPLEJO sobre la plataforma de MySQL.
Figura III.15: Tiempos de las consultas de tipo DECIMAL en CryptDB y en MySQL.
TEXT. En la figura III.16, se presentan los tiempos de las tres consultas de distinta complejidad sobre el tipo TEXT, sobre CryptDB y sobre MySQL.
Figura III.16: Tiempos de las consultas de tipo TEXT en CryptDB y en MySQL.
De nuevo, los tiempos de CryptDB son mucho mayores que los de MySQL. Es en esta gráfica donde más se nota la diferencia, ya que las consultas más rápidas realizadas a través de CryptDB
19
en la última base de datos, tienen un valor final de 2000 ms, mientras que la más lenta de MySQL duró 80 ms. Para calcular el porcentaje de sobrecarga en este caso se toman, de nuevo, la mitad de los valores máximos de cada plataforma. En este caso 2000 ms para CryptDB y 40 ms para MySQL. El resultado es una sobrecarga del 5000 %, mayor que todas las anteriores. Por otro lado, realizando el cálculo sobre una base de datos menor (1000 tuplas/tabla), utilizando 0.23 ms para MySQL y 95 ms para CryptDB, el porcentaje de sobrecarga resultante es 41300 %. Esta gran sobrecarga se debe a que las consultas de tipo TEXT sobre una base de datos pequeña en MySQL son mucho más rápidas que sus homónimas en CryptDB, por ello la diferencia es mucho mayor. De ambos resultados se deduce que, en un escenario con este tipo de dato, donde más eficiencia se perdería sería en un escenario con una base de datos pequeña, ya que la diferencia entre ambas plataformas sería mayor.
VARCHAR. La representación gráfica de las consultas de VARCHAR, realizadas sobre MySQL y CryptDB, se encuentran en la figura III.17.
La causa de la disminución del tipo VARCHAR entre los tamaños de base de datos de 5000 y 7000 tuplas/tabla se describe en el apartado referente a la comparativa de capas. Se puede observar que este tipo de dato es el más rápido en MySQL, ya que su consulta más lenta en la mayor base de datos duró un total de 0.18 ms. El hecho de que sean consultas tan rápidas, provoca a su vez que la sobrecarga temporal también sea la mayor. Ya que utilizando la misma metodología que en casos anteriores para estimar el porcentaje aproximado, es decir, cogiendo la mitad de los valores máximos, primero en la mayor base de datos (30000 tuplas/tabla), donde los valores serían 450 ms para CryptDB, y 0.09 ms para MySQL. El resultado final es una sobrecarga temporal del 50000 %, un porcentaje muy elevado. Por otro lado, realizando el mismo cálculo en una base de datos menor de 1000 tuplas/tabla, los valores de ambas plataformas serían 0.18 ms para MySQL y 60 ms para CryptDB, el porcentaje resultante de sobrecarga se encontraría entorno al 35000 %. Ambas sobrecargas, tanto en una base de datos pequeña como en una mucho mayor, son realmente elevadas. Por último, la razón del pico de la gráfica de VARCHAR BÁSICO en 5000 tuplas/tabla está descrito en el apartado de comparativa de capas.
Figura III.17: Tiempos de las consultas de tipo VARCHAR en CryptDB y en MySQL.
20
Sin embargo, no olvidar que estos porcentajes son resultados numérico. A pesar de que la sobrecarga en este tipo sobre la base de datos de 30000 tuplas/tabla tenga un valor 5000 veces más grande que en MySQL, los tiempos de VARCHAR en CryptDB son los más veloces. Un usuario no notará mucha diferencia en cuanto a calidad de servicio, entre 0.09 ms y 450 ms. Por lo tanto, aunque sean dos magnitudes con mucha diferencia entre ellas, a la hora de llevar CryptDB a un sistema real, el tipo VARCHAR seguiría siendo una buena opción.
En conclusión, los resultados generales coinciden con lo que se esperaba intuitivamente: los tiempos de CryptDB son mayores que los de MySQL. Sin embargo, dentro de estas sobrecargas temporales que causa CryptDB, se han observado los tipos de datos más perjudicados. La proporción de mayor diferencia fue la de los tipos VARCHAR pero, como ya se comenta en ese análisis, los tiempos de CryptDB siguen siendo los más bajos y, por ello, los tipos VARCHAR seguirían siendo viables en un sistema real. Por otro lado, la sobrecarga en el tipo DECIMAL resultó ser mucho más baja que la de los demás tipos, con un 800 %.
Cabe destacar que estos cálculos de proporciones son unas aproximaciones muy relativas, ya que no se está teniendo en cuenta la complejidad de la consulta, solo se coge la mitad del valor máximo entre las tres. Son cálculos con el mero de fin de estimar las dimensiones de los porcentajes referentes a la sobrecarga. Por ello, si se quisiera analizar un escenario en concreto, sería necesario realizar unos cálculos más precisos teniendo en cuenta los niveles de complejidad.
COMPARATIVA DE TAMAÑOS
La última comparativa a realizar es sobre los tamaños de las bases de datos entre MySQL y Cry- ptDB. A partir de estos resultados es posible deducir la sobrecarga de tamaño que causa la utilización de CryptDB. Para ello, tras la creación de cada nueva base de datos, se almacenó el valor de su tama- ño. De este modo, es posible representar los MB que ocupa cada base de datos en cada experimento, como se muestra en la figura III.18.
Se puede observar como la base de datos más pequeña, 100 tuplas/tabla, ocupa en MySQL menos de 0.5 MB, y la de CryptDB ya se encuentra cerca de los 50 MB. Esto significa que la base de datos de CryptDB es 100 veces mayor que la de MySQL. Sin embargo, esta diferencia se atenúa a medida que aumenta la base de datos, basta con observar que en el último experimento (30000 tuplas/tabla), el resultado es que la base de datos de CryptDB es 9 veces mayor que la de MySQL.
Esta atenuación viene dada porque en el tamaño de la base de datos de CryptDB se está incluyendo también el tamaño de la base de datos empotrada (apartado 2.2.2 del anexo 2), la cual ocupa un tamaño constante, ya que describe la estructura lógica de la base de datos y, mientras esta no cambie, su tamaño tampoco variará. Por ello esta diferencia es mucho más notable cuanto menor sea la base de datos.
De la misma forma que el espacio ocupado por la base de datos empotrada causa una gran diferencia en las bases de datos menores, se irá reduciendo a medida que ambas bases de datos crecen de tamaño. Sin embargo, llegará un punto en donde el tamaño de la base de datos empotrada se volverá despreciable, y la diferencia entre MySQL y CryptDB comenzará a aumentar.
Para este estudio, con la estructura lógica de la la base de datos «Deportes» (representada en la figura III.2) es posible realizar una estimación de dicho punto, y saber a partir de que dimensiones se comenzará a disparar la diferencia entre CryptDB y MySQL. La estimación se representa en la tabla II.
Donde el parámetro «Diferencia» se calcula como:
21
Diferencia = Tamano CryptDB Tamano MySQL .
Se puede observar que, en algún punto entre los tamaños de bases de datos de 15000 y 30000 tuplas/tabla, la diferencia entre MySQL y CryptDB comienza a aumentar de nuevo, es decir, el tama- ño de la base de datos empotrada se vuelve despreciable. A partir de este punto, la diferencia entre CryptDB y MySQL irá siempre en aumento.
Figura III.18: Tamaños de las bases de datos en MySQL y CryptDB.
Tabla II: Valores representados en la figura III.18.
Tuplas/tabla MySQL (MB) CryptDB (MB) Diferencia ( %) 100 0,312 31,303 100,17
300 0,593 33,625 56,69
500 0,875 31,318 42,65
700 1,078 43,16 40,03
1000 1,437 48,131 33,48
3000 2,500 31,303 23,01
5000 4,953 58,812 11,87
7000 9,234 128,312 13,89
10000 15,312 145,312 9,48
15000 24,359 215,375 8,84
30000 39,578 355,671 8,98
22
IV. Conclusiones y líneas futuras El objetivo principal de este estudio era analizar CryptDB, un producto aún en desarrollo, y ve-
rificar que todas las funcionalidades y ventajas que ofrecía su versión teórica, estaban presentes en su implementación real. Para ello se dividió el proyecto en una tarea principal, y otras dos subtareas, igual de necesarias para alcanzar el objetivo final.
Primero se estudió el sistema en detalle. Dado que CryptDB es un software complejo, era necesario conocerlo detalladamente para llevar a cabo de forma exitosa los siguientes objetivos. En este estudio se comprobó como, efectivamente, CryptDB realizaba un papel de intermediario entre el usuario y la base de datos. Cifraba las consultas, se ejecutaban en el motor MySQL, y se recuperaban los datos correctamente. También se observó como el sistema utilizaba una base de datos paralela para almacenar los metadatos, referentes a la estructura lógica de la base de datos. Y, por último, siguiendo el flujo natural del programa, se analizaron sus principales algoritmos de reescritura de consultas. Conocer el producto con este nivel de detalle, posibilitó que se llevasen a cabo de manera correcta las siguientes tareas.
Tras dicho estudio, el siguiente objetivo fue la integración del sistema con una aplicación real. La aplicación se desarrolló en lenguaje Java, para que llevase a cabo la funcionalidad de interfaz gráfica y facilitase el uso de CryptDB. El resultado fue satisfactorio, ya que se utilizaron directamente librerías Java, y no hubo ningún tipo de problema a la hora de interactuar con CryptDB desde el software externo. La aplicación funciona correctamente, realizando las acciones deseadas sobre una base de datos cifrada a través de su motor de cifrado.
Por último, se llevó a cabo un análisis de prestaciones del sistema. Para ello se planteó primero una batería de pruebas, ejecutada a través de otra aplicación Java. Una vez finalizado el refinado de las pruebas, se procedió a su realización. Los resultados finales fueron almacenados, posibilitando así su posterior analítica. Dentro de este estudio de prestaciones, se realizaron comparaciones entre elementos internos del sistema, como las capas de cifrado o la complejidad de las consultas, y comparaciones de CryptDB con otra plataforma de bases de datos como es MySQL.
Como resultado de toda la investigación planteada, se puede concluir que CryptDB es un sistema que cubre las necesidades para las que fue planteado, pero a costa de una gran cantidad de recursos. La idea de CryptDB nació para solucionar un problema a la hora de externalizar las bases de datos, cifrando su información y permitiendo la realización de operaciones sobre su texto cifrado. Se ha comprobado y estudiado que CryptDB, efectivamente, realiza tales acciones, y que su implementación funciona. Incluso no presenta dificultades al conectarlo con terceras aplicaciones. Sin embargo, el sistema consume un número de recursos excesivo en la realización de sus tareas.
A pesar de la sobrecarga excesiva que muestra el sistema en general, se han observado algunos escenarios donde podría ser viable su uso. Por ejemplo, los tiempos de consulta sobre VARCHAR son los más bajos del sistema, por lo que podría utilizarse CryptDB en una base de datos especializada en datos de este tipo. Otro posible escenario viable sería una base de datos de tipos DECIMAL, ya que la sobrecarga de CryptDB sobre este tipo de datos es la menor. Por otro lado, el tipo de datos sobre el que no se debe utilizar CryptDB en un caso real es el tipo TEXT, el cual se ha demostrado que ofrece las prestaciones más bajas en el sistema seguro.
En resumen, CryptDB ha demostrado que puede realizar las tareas para las que fue creado, no obstante, sus prestaciones exigen un gasto de recursos excesivo. El sistema seguro intenta cubrir una
23
necesidad que se ha demostrado que existe, y por ello es un enfoque que debe continuar en desarrollo. Puede que CryptDB no haya terminado como un producto completo y cerrado, pero ha dejado planteada la idea que soluciona un problema real y actual.
En este momento, tal y como está el sistema CryptDB, su principal línea de trabajo futura es mejorar la eficiencia de los algoritmos. Ya se ha visto que consumen un gran número de recursos y que, a la hora de llevarlo a un sistema real, reduciría considerablemente su calidad de servicio. Por ello, si se consiguiese solucionar ese problema, CryptDB podría dar el salto a escenarios comerciales. Por otro lado, también se podrían crear implementaciones de nuevas capas de cifrado que soportasen otras operaciones de consulta. De esta forma, se podrían mejorar las funcionalidades del sistema, ofreciendo un servicio mucho más completo.
V. Bibliografía [1] Data encryption standard (aes), October 1999. Publication 46-3 - http://csrc.nist.gov/
publications/fips/fips46-3/fips46-3.pdf.
[2] Announcing the advanced encryption standard (aes), November 2001. Publication 197 - http: //csrc.nist.gov/publications/fips/fips197/fips-197.pdf.
[3] Secure hash standard, March 2012. Publication 180-4. http://csrc.nist.gov/ publications/fips/fips180-4/fips-180-4.pdf.
[4] Alexandra Boldyreva, Nathan Chenette, Younho Lee, and Adam ONeill. Order-preserving sym- metric encryption. In Antoine Joux, editor, Advances in Cryptology - EUROCRYPT 2009, volume 5479 of Lecture Notes in Computer Science, pages 224–241. Springer Berlin Heidelberg, 2009.
[5] D. Catalano. Paillier’s cryptosystem. Departament of Computer Sciente, University of Stanford, September 2009. http://cs.au.dk/~stm/local-cache/gentry-thesis.pdf.
[6] E. F. Codd. A relational model of data for large shared data banks. IBM Research Laboratory, San Jose, California, 1970.
[7] Universidad Autónoma del Estado de Morelos. Mysql. http://www.gridmorelos. uaem.mx/~mcruz//cursos/miic/MySQL.pdf.
[8] V. Delgado and Palacios R. Introducción a la criptografía: Tipos de algoritmos. Revista de la asociación de ingenieros ICAI. Univerisdad Pontificia Comillas, February 2006. https: //www.icai.es/publicaciones/anales_get.php?id=1210.
[9] Yevgeniy Dodis and Jonathan Katz. Chosen-ciphertext security of multiple encryption. In Joe Kilian, editor, Theory of Cryptography, volume 3378 of Lecture Notes in Computer Science, pages 188–209. Springer Berlin Heidelberg, 2005.
[10] W.F. Ehrsam, C.H.W. Meyer, J.L. Smith, and W.L. Tuchman. Message verification and trans- mission error detection by block chaining, 1978. US Patent 4,074,066.
[11] IBM X force Team. Ibm x-force 2012 trend and risk report, March 2013. http://www.ibm. com/ibm/files/I218646H25649F77/Risk_Report.pdf.
[12] C. Gentry. A fully homomorphic scheme. Departament of Computer Sciente, University of Stan- ford, September 2009. http://cs.au.dk/~stm/local-cache/gentry-thesis. pdf.
[13] H. Hacigumus, B. Iyer, and S. Mehrotra. Providing database as a service. In Data Engineering, 2002. Proceedings. 18th International Conference on, pages 29–38, 2002.
[14] MIT CSAIL. CryptDB: Protecting Confidentiality with Encrypted Query Processing, In Procee- dings of the 23rd ACM Symposium on Operating Systems Principles (SOSP), Cascais, Portugal, October 2011. Popa, R. A., Redfield, C. M. S., Zeldovich, N. and Balakrishnan, H.
[15] S. Pachev. Grammar rules module. In Understanding MySQL Internals, pages 169 – 172. OReilly Media, Inc., 2007.
[16] E. Rescorla. Http over tls. RTFM, Inc., May 2000. http://tools.ietf.org/html/ rfc2818.
[17] R. Rivest. The md5 message-digest algorithm. MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. http://www.ietf.org/rfc/rfc1321.txt.
[18] B. Schneier. Description of a new variable-length key, 64-bit block cipher (blowfish). In Ross Anderson, editor, Fast Software Encryption, volume 809 of Lecture Notes in Computer Science, pages 191–204. Springer Berlin Heidelberg, 1994.
[19] B. Schwartz, P. Zaitsev, and V. Tkachenko. Hight Performance MySQL, chapter 6. Query Per- formance Optimization. O’Reilly, third edition, March 2012.
[20] D. X. Song, D. Wagner, and A. Perrig. Practical techniques for searches on encrypted data. Security and Privacy, 2000. SP 2000. Proceedings. 2000 IEEE Symposium, May 2000.
[21] M. Turner, D. Budgen, and P. Brereton. Turning software into a service, pages 38–44. Computer., 36(10), 2003.
25
1.1.1. Introducción
Los seres humanos llevan almacenando información desde hace mucho tiempo. Antiguamente el método para guardar datos era manualmente, escribiendo en hojas de papel que posteriormente eran archivadas en bibliotecas y oficinas. Sin embargo, alrededor de los años 60, cuando el ordenador comenzó a estar al alcance de entidades privadas, nació el concepto de base de datos aplicado a la informática1. Puede que al principio no hubiese consciencia de la importancia de estos sistemas pero, actualmente, se han convertido en un pilar base para cualquier sistema informático.
El período histórico en el que se encuentra hoy en día la humanidad es la era de la información, era en la que los datos en sí son uno de los recursos más preciados. Actualmente la mayoría de las actividades realizadas por un individuo, ya sean ociosas, de carácter laboral o de carácter social, se llevan a cabo a través de dispositivos electrónicos como tablets o smartphones, conectados a la red de la información y de las comunicaciones, Internet.
En este contexto, prácticamente cualquier tipo de actividad implica una generación o manipulación de datos. Para gestionar correctamente toda esa información es necesario, en primer lugar, almacenarla de tal forma que se pueda recuperar con facilidad, en segundo lugar, minimizar su redundancia y, por último, garantizar que los datos sean siempre correctos. De dichas necesidades nace la importancia actual de las bases de datos.
Por ejemplo, un servicio de reproducción de vídeo necesitará almacenar principalmente datos multimedia. Utilizando una base de datos es posible almacenar la información multimedia según una serie de parámetros que acelerarán su posterior búsqueda y recuperación. Otro ejemplo es el de una página web que almacene numerosos artículos, ya que el orden que proporcionan estos sistemas gestores de datos es imprescindible para que el sistema trabaje de manera eficaz a la hora de realizar consultas sobre grandes volúmenes de texto.
En esta sección se define qué es una base de datos y se enumeran sus principales características. También se repasa brevemente su funcionamiento general junto con sus ventajas y desventajas. Fi- nalmente, se realiza una clasificación de los sistemas más comunes como introducción a los sistemas relacionales, que son los más relevantes para este estudio.
DEFINICIÓN
Una base de datos es un volumen de información almacenado de forma organizada y que está gestionado por distintos sistemas de creación, manipulación y consulta de datos. Dicha organización es lo que permite la búsqueda de datos concretos entre grandes cantidades de información de manera rápida y eficaz2.
Las principales características que debe cumplir una base de datos son3:
Garantizar redundancia mínima. Es necesario que un dato se repita el menor número de veces posible en una base de datos para economizar los recursos de espacio disponibles y facilitar en la mayor medida de lo posible las búsquedas.
Soportar acceso concurrente. Una base de datos ha de posibilitar a los usuarios el acceso simultáneo a su información de manera fiable.
Preservar la integridad de la información. Los datos almacenados deben de ser siempre física y contextualmente correctos.
Ofrecer una interfaz. Para que una base de datos pueda ser utilizada correctamente es necesario que tenga implementada una vía de comunicación con otros lenguajes de programación.
En lo referente a la última característica, la interfaz de comunicación, lo más habitual es que las propias bases de datos incluyan un Sistema de Gestión de Base de Datos o DBMS, DataBase Management System4. Se trata de un software específico que es el intermediario entre las propias bases de datos, las aplicaciones que hacen uso de ellas y los usuarios. En la figura 1.1 se puede observar una representación gráfica de la funcionalidad principal de este sistema gestor.
El DBMS está formado generalmente por un lenguaje de defición de los datos o DDL, Data Defi- nition Language, encargado de definir, crear y relacionar las estructuras de datos que serán utilizadas, y por un lenguaje de manipulación de los datos, DML, Data Manipulation Language, cuyas acciones principales son las de insertar nuevos datos y modificar o eliminar los ya existentes.
Figura 1.1: Esquema básico de la comunicación con una base de datos.
VENTAJAS DE UNA BASE DE DATOS
Las relaciones de los distintos elementos de la base de datos permiten utilizar un mismo dato en varios contextos sin necesidad de su replicación.
Cuando se crean los elementos de la base de datos, el sistema permite definir qué tipos de datos contendrán o los rangos entre los que estarán comprendidos. Esto facilita el mantener la integridad de los datos y que no se almacene ningún valor erróneo.
Implementar el acceso a una base de datos resulta mucho más sencillo gracias al DBMS, que elimina la dependencia de los datos respecto a las aplicaciones que hacen uso de ellos y simplifica así el mantenimiento de estas últimas.
La información se gestiona a través de un sistema centralizado, por lo que proporcio- nar acceso a varios usuarios o aplicaciones a un mismo núcleo de datos es mucho más sencillo que si se trabajara con sistemas independientes.
DESVENTAJAS DE UNA BASE DE DATOS
Las bases de datos tienen un nivel de complejidad que requiere un grado de compren- sión elevado para su correcto uso. Un mismo esquema lógico puede ser implementado de muchas formas distintas. Sin embargo, cada una de estas implementaciones pre- sentará diferentes ventajas respecto a las otras como una mayor velocidad a la hora de consultar un determinado campo o realizar algún tipo de operación. Por lo tanto, el desarrollador debe conocer bien los distintos modelados de las bases de datos para sacar partido a sus distintas funciones según las necesidades del sistema.
Almacenar toda la información en un mismo núcleo tal y como lo hacen las bases de datos hace al sistema muy vulnerable a fallos. Por ejemplo, en el caso de que se cor- tase el suministro eléctrico a los servidores que mantienen la base de datos, el sistema quedaría totalmente inutilizable durante el período de tiempo que tardase en recuperar la energía, con riesgo de pérdida de información en los equipos debido al apagado repentino. Esta vulnerabilidad hace necesario replicar el sistema para sustitución en caso de fallo y mantener al día las copias de seguridad o backups5.
1.1.2. Clasificación
Dado que existen muchos tipos de bases de datos, es necesario clasificarlos de alguna manera con el fin de que sea más sencillo para los usuarios evaluar las opciones según sus necesidades. Debido a esta variedad es posible repartirlas de numerosas maneras siguiendo distintos criterios como, por
ejemplo, el contenido que están destinadas a almacenar o los tipos de sistemas con los que van a trabajar. Sin embargo, lo más común es agruparlas según su funcionamiento.
De esta forma, las bases de datos se dividen en dos grandes grupos principales. Las bases de datos relacionales y las bases de datos no relacionales.
MODELO RELACIONAL
El modelo de bases de datos relacional fue creado por un empleado de IBM a finales de los años 60 [6]. Este modelo surge de la necesidad de que los usuarios no deberian tener que conocer la forma en la que los datos están almacenados y, aun en caso de que su estructura cambie, estos cambios no deberían verse reflejados en las aplicaciones externas.
El modelo de relación se basa en almacenar los datos en tablas, formalmente descritas, que se dividen en filas o tuplas y columnas o atributos. Dichas tablas se relacionan entre sí a través de distintos tipos de claves. Las categorías de datos que contienen las tablas son las columnas, donde se le asigna un identificador y un tipo al dato (por ejemplo un dato llamado «Nombre» de tipo texto u otro dato llamado «Edad» de tipo numérico). En las filas es donde se encontrarían todas las instancias del dato almacenadas en la base de datos. Un ejemplo de tabla de una base de datos relacional se puede encontrar en la figura 1.2.
Siguiendo este esquema de almacenamiento, si la estructura lógica de la base de datos cambia, es posible eliminar o modificar elementos y reasignar claves sin necesidad de reorganizar las tablas. El modelo relacional también aporta un fácil acceso a la información, mejorando significativamente los tiempos de ejecución de consultas sobre grandes volúmenes de datos. Para nuevas inserciones en el sistema únicamente se han de guardar las nuevas instancias en la tabla correspondiente, por lo que también son bases de datos fácilmente extensibles.
En resumen, las principales características del modelo relacional de bases de datos son:
Posibilidad de modificar el esquema lógico de los datos sin necesidad de reorganizar las tablas.
Acceso eficiente a los datos.
Bases de datos fácilmente extensibles.
El modelo de bases de datos relacional se ha convertido en la actualidad en el más importante debido a su alto rendimiento. El gestor de base de datos relacional más popular es MySQL6, que se describe con más detalle en la siguiente sección (1.1.3). Dado que MySQL es un software de código abierto, se han ido desarrollando numerosas versiones del mismo a lo largo de los años. Un claro ejemplo de ello es MariaDB7, que ofrece nuevos motores de búsqueda y novedades en los métodos de almacenamiento.
En el caso relacional, de lo que se encargan los motores de seguridad por cifrado (más detalle en la sección 1.2.3) es de proteger las tablas y la información que estas contienen. Ese será el trabajo del sistema tratado en este estudio, CryptDB, que ha sido desarrollado y trabaja sobre MySQL.
MySQL es de suma importancia en este estudio ya que es el motor sobre el que está desarrollado y se ejecuta CryptDB [14].
6http://www.mysql.com 7https://mariadb.org/
MODELO NO RELACIONAL
El modelo de base de datos no relacional es aquel que, como su propio nombre indica, no sigue el esquema del modelo relacional. Son bases de datos que usan sistemas de organización distintos a las tablas y filas indicadas en el apartado anterior. A pesar de que el modelo relacional está presente en la mayoría de los sistemas, en la actualidad los modelos no relacionales son cada vez más utilizados, especialmente por grandes compañías como Google o Amazon8. Este cambio se debe principalmente a dos factores. En primer lugar, la infraestructura de la base de datos relacional no escala bien con grandes cantidades de datos, por lo que si la base de datos crece indefinidamente llega un punto en el que los costes de mantenimiento son excesivos. En segundo lugar las bases de datos relacionales no soportan bien las búsquedas no estructuradas como las que se realizan en cualquier buscador como Google. Ejemplos de bases de datos que siguen modelos no relacionales son las bases de datos jerárquicas o las bases de datos orientadas a objetos.
Bases de datos jerárquicas. Son aquellas que se dividen en nodos de información entre los que se establece una jerarquía. Los nodos son puntos conectados entre sí formando un árbol invertido. Cada nodo hijo tiene un nodo padre que, a su vez, puede tener varios nodos hijos. El único nodo que no
tiene nivel superior es el comunmente conocido como nodo raíz. El esquema general de estas bases de datos es el que aparece en la figura 1.3.
Figura 1.3: Ejemplo de una base de datos jerárquica.
Uno de los sistemas más potentes y conocidos de este modelo de bases de datos es IMS9, Infor- mation Management System, desarrollado por IBM.
Bases de datos orientadas a objetos. Son aquellas en las que la unidad de información es el «obje- to» y las relaciones son las propias que tienen los objetos entre sí 10. No son más que el resultado de una integración de un lenguaje de programación orientado a objetos con un sistema gestor de base de datos. Han sido diseñadas para trabajar en conjunción con dichos lenguajes (Java, C++ y similares), de modo que su rendimiento en este ámbito es súmamente elevado. Son especialmente recomendables para los sistemas que trabajan con tipos de datos de gran complejidad.
En este ámbito de bases de datos destaca PostgreSQL 11, otro software que, al igual que MySQL, es de código abierto.
Figura 1.4: Ejemplo de una base de datos orientada a objetos.
1.1.3. MySQL
MySQL nació alrededor de la década de los 90 y es uno de los sistemas de bases de datos más utilizados actualmente. Muchas de las empresas más poderosas, como pueden ser Google, Facebook o Adobe, utilizan MySQL para administrar algunos de sus sistemas de datos12 (nótese que no todos, como se dice en el apartado 1.1.2 de la sección anterior). De la misma manera, el producto que atañe a este estudio, CryptDB, fue creado para trabajar sobre MySQL. Sin embargo podría funcionar en otros sistemas similares con unos pocos cambios.
MySQL se basa en una gestión multihilo y multiusuario de bases de datos relacionales. Su estructura es la de un servidor en la que existen distintos usuarios con distintos privilegios. El perfil más alto es el de administrador, conocido como la cuenta root, que tiene todos los privilegios existentes y, por lo tanto, puede acceder y modificar la base de datos como desee. Por debajo del administrador pueden existir distintos perfiles de usuario, variando sus privilegios (como la lectura y escritura de una tabla concreta o, directamente, el acceso a una base de datos) según sea conveniente. Estos perfiles también son gestionados por el administrador. Todos los usuarios necesitan una cuenta con un nombre y una contraseña para acceder al sistema.
Dentro del servidor, la información se reparte en bases de datos MySQL. En estas bases de datos es donde se crean las distintas tablas, estructuradas en filas o tuplas, y columnas o atributos. Durante la creación de estas tablas es preciso indicar las columnas que tendrá y los tipos que contendrá cada una. También es imprescindible señalar cual será el atributo identificativo de cada tupla, para poder diferenciar de manera única cada elemento dentro de la base de datos. Por último, en los casos en los que existan relaciones entre distintas tablas, también será necesario declararlas dentro de la estructura lógica de las mismas.
Para recuperar la información almacenada, MySQL funciona mediante consultas. Estas se envían al servidor con una sintaxis muy específica y este responderá con el resultado de la búsqueda solicitada en forma de tabla.
CARACTERÍSTICAS
Inicialmente MySQL carecía de algunas características clave en las bases de datos como la integridad referencial13 o las transacciones14. Sin embargo gracias a su simplicidad atrajo a un gran número de desarrolladores, lo que ocasionó la mejora gradual del sistema en muchos aspectos hasta el día de hoy.
En las últimas versiones de MySQL se pueden destacar las siguentes características [7]:
Prioriza la velocidad en las consultas y la robustez.
Posibilita el uso de una amplia gama de tipos de datos para los distintos campos de las tablas.
Garantiza la buena portabilidad entre distintas plataformas y sistemas operativos.
Agrupa cada base de datos en tres archivos: estructura, información e índices.
Permite aprovechar la potencia de las máquinas multiprocesador gracias a su implementación como sistema multihilo.
Ofrece un buen grado de seguridad debido al sistema de cuentas de usuario.
En resumen, MySQL es un sistema gestor de bases de datos con un gran potencial. A pesar de ser uno de los sistemas gestores más utilizados, MySQL también presenta ciertas desventajas frente a otros sistemas, por lo que podría no ser siempre la elección acertada.
Como ventajas, en primer lugar, MySQL posee una gran velocidad para realizar operaciones, lo que lo convierte en uno de los gestores de bases de datos con mejor rendimiento. A pesar de ello no deja de tener bajos costes en requisitos computacionales, lo que posibilita que sea ejecutado en máquinas con escasos recursos. En segundo lugar, su configuración e instalación son sencillas y ello promueve una alta portabilidad. Por último, la integridad de los datos que ofrece MySQL asegura su consistencia.
En cuanto a los aspectos negativos hay dos especialmente remarcables. El primero es que muchas de las funcionalidades de MySQL no se encuentran documentadas, ya que es un software de códi- go abierto en continuo desarrollo. Y el segundo es que este gestor puede no ser tan intuitivo como otros programas más orientados a usuarios no preparados como, por ejemplo, Access15. Esta última desventaja esta directamente derivada de la complejidad que acompaña a las bases de datos.
FUNCIONAMIENTO
El lenguaje SQL tiene una sintaxis muy específica. En términos generales se puede dividir, como en cualquier otro gestor, en comandos de definición de datos o DDL, y en comandos de manipulación de datos o DML16, mencionados ambos en el apartado 1.1.1 de esta sección.
Los DDL se encargarán de crear las estructuras de las bases de datos y de las tablas. Las acciones mas importantes en el ámbito DDL son:
CREATE Crea elementos en la base de datos. ALTER Altera estructura de la base de datos. DROP Elimina elementos de la base de datos. RENAME Renombra elemento de la base de datos. TRUNCATE Elimina todas las tuplas de una tabla.
Por otro lado, los comandos DML llevarán a cabo las distintas consultas y acciones sobre los datos. Las principales consultas a través del lenguaje DML son:
SELECT Consulta datos de la base de datos. INSERT Inserta datos en una tabla. UPDATE Actualiza datos que se encuentran en una tabla. DELETE Elimina datos de una tabla. CALL Llama a un procedimiento MySQL o a un subprograma
Existe otro tipo principal de consultas llamado DCL (Data Control Language) pero cuya funcionalidad no está tan relacionada con los propios datos como los dos anteriores. Su objetivo se centra principalmente en gestionar los derechos, permisos y otros parámetros de administración del sistema de la base de datos. Sus dos acciones principales son:
GRANT Otorga privilegios de acceso a los usuarios. REVOKE Elimina privilegios de acceso a los usuarios.
1.2. Seguridad
1.2.1. Introducción
Cada día personas mal intencionadas intentan acceder a datos de carácter privado y, en la ma- yoría de los casos, este acceso no autorizado a puede causar graves problemas. Una de las posibles consecuencias de una intrusión o un mal uso de las herramientas de seguridad es la pérdida de datos, causando numerosos trastornos17. En ocasiones estos datos pueden estar dañados o corruptos y son imposibles de recuperar si no se tienen copias de seguridad al día.
Otro grave problema en la seguridad informática es el robo de información sensible. Tanto empresas como usuarios suelen almacenar en su sistema informático datos confidenciales que, en caso de pérdida, podrían ocasionar daños económicos o incluso de imagen18.
DEFINICIÓN
La seguridad son todos aquellos medios o herramientas utilizados para conservar cuatro principios básicos de la información. Estos principios son la disponibilidad, la confidencia- lidad, la integridad y el no repudio de los datos de un sistema19.
En los sistemas de información no solo existen amenazas de carácter informático, también es necesario tener en cuenta sucesos externos. En resumen, existe una gran variedad de situaciones que pueden llegar a comprometer un sistema de información y, por ello, a continuación se presenta una lista general de las amenazas más comunes20:
Usuarios: causa muy común de fallos de seguridad en un sistema. En algunos casos sus acciones comprometen al sistema, bien sea porque tienen permisos o privilegios demasiado elevados o no se han restringido acciones innecesarias.
17https://www.bostoncomputing.net/consultation/databackup/dataloss 18http://www.sans.org/reading-room/whitepapers/awareness/data-leakage-threats-
Programas maliciosos: creados con la idea de perjudicar o hacer uso ilícito de los recursos. Se instalan de alguna manera en el sistema y permiten el acceso a individuos ajenos o bien modifican datos. Estos p

CRYPTDB: SEGURIDAD EN LAS BASES DE DATOS …

Documents

Transcript of CRYPTDB: SEGURIDAD EN LAS BASES DE DATOS …