Transcript of 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 re- quiere 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 soft- ware 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 ejem- plo, 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 segun- do 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 apli- caciones 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 pres- taciones 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 princi- pal 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 di- cho
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 ac-
tualidad 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
consul- tas 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 velo- cidad 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 com- plejidad 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, si- guiendo un crecimiento casi lineal. Entre
los valores de bases de datos de 5000 y 7000 tu- plas/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 simi- lar, 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, don- de 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 eficien- tes. 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 prue- bas, 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 com- plejo, 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 con- trario, 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 tar- dan 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 comple- jidad 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, especial- mente 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 consul- tas 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 necesi- tan 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, efectivamen- te, 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 res- pecto 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 so- brecarga 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 sobre- carga 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 simi- lares 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 obser- var
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 valo- res 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 mu- cho 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 so- brecarga 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 tiem- pos 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 dife- rencia 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 nece- sario 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 usua- rio 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, siguien-
do 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 elemen- tos 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 desarro- llo. 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, vo- lume 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 mul- timedia. 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 recupe- rar 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 co- mo 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 estruc- tura 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 integri- dad 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 funcio- nalidad 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 empre- sas 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