Inicio / Blog / Bases de datos NoSQL. Rendimiento y ... ¿seguridad?

Bases de datos NoSQL. Rendimiento y ... ¿seguridad?

Publicado el 03/02/2015, por Antonio López (INCIBE)
Bases de datos NoSQL. Rendimiento y ... ¿seguridad?

Hoy en día es una realidad el enorme peso que supone el proceso y mantenimiento de la información disponible online y sobre todo, su utilización. Un análisis apropiado de esos datos puede proporcionar conclusiones fundamentales para distintos objetivos. Así, empresas con intereses comerciales extraen los patrones de comportamiento de sus clientes con objeto de mejorar sus ventas. Del mismo modo y directamente vinculado a la seguridad, la observación y análisis aplicados a corrientes de pensamiento acciones y comportamiento humano juega un papel protagonista en cuestiones de defensa y protección de una nación.

 

El imparable crecimiento de datos en Internet.

Algunas cifras nos aproximan la realidad de la información que se maneja en Internet:

Según, Eric Schimdt presidente y director de Google 2001-2011, el volumen de datos generado en internet cada dos días es equivalente al acumulado hasta 2003.

IBM por su parte, estima que en 2020 se generen 40 zetabytes de datos frente a los 3,2 actuales, lo que viene a ser 43 trillones de Gigabytes, unas 300 veces más que en 2005.

Google proporciona unos 3,5 billones de búsquedas diarias que suponen consultas a bases de datos de dimensiones brutales.

Es patente que el crecimiento de internet y los volúmenes de datos, almacenamiento y análisis de los mismos traen de la mano soluciones eficaces capaces de lidiar con estas cifras. Estas necesidades han impulsado la consolidación de las bases de datos no relacionales o NoSQL, cuyas características de portabilidad, escalabilidad y de distribución entre múltiples sistemas hacen que el uso de estas tecnologías sea casi imprescindible.

 

Bases de DATOS. SQL vs NoSQL

Históricamente, una base de datos relacional focaliza el interés en la fiabilidad de las transacciones bajo el conocido principio ACID, acrónimo de Atomicity, Consistency, Isolation and Durability (Atomicidad, Consistencia, Aislamiento y Durabilidad en español). Bajo esas propiedades se pretende que una transacción sobre una base de datos siempre se complete o no (atomicidad), que los datos se mantengan en estado válido en todo momento (consistencia), que sea independiente (aislamiento) y que sea permanente frente a fallos del sistema (durabilidad).

El principio ACID aporta una robustez que colisiona con el rendimiento y operatividad a medida que los volúmenes de datos crecen.

- Principio ACID, típico de bases de datos relacionales -

Cuando la magnitud y el dinamismo de los datos cobran importancia, el principio ACID de los modelos relacionales queda en segundo plano frente rendimiento, disponibilidad y escalabilidad, las características más propias de las bases de datos NoSQL. Hoy en día, los modernos sistemas de datos en internet se ajustan más al también conocido principio BASE, acrónimo de Basic Availability (disponibilidad como prioridad) Soft state (la consistencia de datos se delega a gestión externa al motor de la base de datos) Eventually consistency (intentar lograr la convergencia hacia un estado consistente)

- Principio BASE, común en BBDD NoSQL -;

La principal diferencia entre una base datos relacional (RDBMS) y una NoSQL estriba en el concepto de la estructura de los datos. Con un modelo NoSQL la información se almacena de modos más flexibles que no tienen la restricción de adoptar un formato predefinido, tal y como ocurre en las bases relacionales (tablas cuya estructura sigue un esquema). Gracias a esto, es mucho más sencillo distribuir los datos entre sistemas sin tener que mantener un complejo mecanismo de migración. Además, este diseño beneficia una escalabilidad horizontal simplemente añadiendo nodos para distribuir la carga, que aventaja la escalabilidad vertical (incremento de potencia de procesado y memoria) necesaria en bases de datos relacionales. Estas razones principalmente, hacen que las bases de datos NoSQL sean las candidatas a adoptar cuando se trate de manejar grandes volúmenes de datos de naturaleza muy variada.

Tipos y clasificación de bases de datos NoSQL

Existen unos 150 tipos de bases de datos NoSQL con diferente arquitectura de datos (basado en documento, en clave/valor, en objetos, en grafos, en columnas, etc.). Entre las más conocidas destacan Cassandra, Hadoop, MongoDB, CouchDB o Redis. Gigantes como Oracle también disponen de una implementación NoSQL.

- Bases de datos NoSQL, cada día mas extendidas -

Según el tipo o modelo escogido para almacenar los datos, las bases de datos NoSQL se agrupan en cuatro categorías principales:

  • Clave/Valor. Los datos son almacenados y se localizan e identifican usando una clave única y un valor (un dato o puntero a los datos). Ejemplos: DynamoDB, Riak, Redis. Amazon y Best Buy entre otros utilizan esta implementación
  • Columnas. Parecido al modelo clave/valor, pero la clave se basa en una combinación de columna, fila y marca de tiempo que se utiliza para referenciar conjuntos de columnas (familias). Es la implementación más parecida a bases de datos relacionales. Ejemplos: Cassandra, BigTable, Hadoop/HBase. Compañias como Twitter o Adobe hacen uso de este modelo.
  • Documentos. Los datos se almacenan en documentos que encapsulan la información en formato XML, YAML o JSON. Los documentos tienen nombres de campos auto contenidos en el propio documento. La información se indexa utilizando esos nombres de campos. Ejemplos: MongoDB, CouchDB. Un caso de uso de esta tecnología lo tenemos con Netflix, empresa que proporciona contenidos audiovisuales online.
  • Grafos. Se sigue un modelo de grafos que se extiende entre múltiples máquinas. Es un modelo apropiado para datos cuyas relaciones se ajustan a este modelo, como por ejemplo redes de transporte, mapas, etc. Ejemplos: Neo4J, GraphBase

Retos de seguridad en bases de datos NoSQL

Dada la amplia variedad de bases de datos NoSQL, es necesario prestar atención a las debilidades genéricas de estos modelos y, en cada caso particular aplicar las medidas necesarias en cada implementación particular. Comparando con las bases de datos relacionales podemos resumir los siguientes campos de seguridad:

Autenticación.

La fortaleza de la autenticación es uno de los campos de batalla donde muchas implementaciones NoSQL muestran debilidad. Es común encontrar que la las bases de datos NoSQL incorporen credenciales por defecto, o incluso sin autenticación necesaria o deshabilitada (por ejemplo, Redis). En muchos casos se basan en entornos de confianza en lugar de autenticación de usuario. Dependiendo del software siempre será un punto fundamental a chequear.

Integridad de los datos.

Siguiendo una filosofía donde prima la disponibilidad y el rendimiento, se penaliza en la integridad de los datos. Por ello es necesario utilizar frecuentemente mecanismos complementarios ajenos al motor de la base de datos para asegurar la integridad.

Confidencialidad y cifrado en el almacenamiento.

Por lo general, el almacenamiento de los datos se realiza en texto plano y salvo escasas excepciones como por ejemplo Cassandra y su tecnología Transparent data encryption, no se incorporan mecanismos de cifrado integrados. En la mayoría de los casos sigue siendo necesario delegar el cifrado a procesos en la capa de aplicación o del propio sistema de ficheros.

Auditoria de datos

La mayoría de bases de datos NoSQL carecen de mecanismos propios y robustos de auditoría de datos, de gran peso a la hora de detectar posibles ataques mediante la observación de eventos sobre registros concretos tal y como se hace en bases de datos relacionales.

Seguridad en las comunicaciones.

El uso de cifrado y protocolo SSL es habitual en bases de datos relaciones, en cambio en sistemas NoSQL generalmente se encuentra deshabilitado por defecto, es opcional (por ejemplo Cassandra), o bien es necesaria una configuración específica en la instalación (MongoDB).

Vulnerabilidades clásicas en base de datos: Aún más inyección.

Finalmente, y haciendo hincapié en uno de los aspectos más ampliamente explotado como es la inyección de comandos debemos tener en cuenta que en las bases de datos NoSQL, las peticiones y llamadas se ejecutan invocando la API correspondiente formateada según una convención común, habitualmente JSON o XML. En este punto, una incorrecta verificación de los parámetros de entrada puede permitir la ejecución de comandos al evaluarse y tratarse en la llamada a la API correspondiente. Las posibilidades de inyección y los riesgos, al utilizarse una API con lenguaje de programación procedimental, son aún mayores que en el caso de bases de datos relaciones donde se usa el lenguaje sql típicamente declarativo y mucho más acotado. Inyección NoSQL y de código javascript son nuevos vectores que amplían la superficie de ataques sobre estas bases de datos

NoSQL está cada vez más presente en las tecnologías actuales de bases de datos y afronta grandes retos para lidiar con los problemas de seguridad que tarde o temprano deberá reforzar.