Instituto Tecnológico y de Estudios Superiores de Occidente

Repositorio Institucional del ITESO rei.iteso.mx

Departamento de Electrónica, Sistemas e Informática DESI - Trabajos de fin de Maestría en Sistemas Computacionales

2017-11

Diseño de marco de referencia para la

seguridad en MongoDB, para implementar en
la micro y pequeña empresa

DeLaMora-Carrillo, Hugo E.

DeLaMora-Carrillo, H. E. (2017). Diseño de marco de referencia para la seguridad en MongoDB,

para implementar en la micro y pequeña empresa. Trabajo de obtención de grado, Maestría en
Sistemas Computacionales. Tlaquepaque, Jalisco: ITESO.

Enlace directo al documento: http://hdl.handle.net/11117/5095

Este documento obtenido del Repositorio Institucional del Instituto Tecnológico y de Estudios Superiores de
Occidente se pone a disposición general bajo los términos y condiciones de la siguiente licencia:
http://quijote.biblio.iteso.mx/licencias/CC-BY-NC-2.5-MX.pdf

(El documento empieza en la siguiente página)

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE OCCIDENTE
Reconocimiento de validez oficial de estudios de nivel superior según acuerdo secretarial
15018, publicado en el Diario Oficial de la Federación el 29 de noviembre de 1976.

Departamento de Electrónica, Sistemas e Informática

MAESTRÍA EN SISTEMAS COMPUTACIONALES

DISEÑO DE MARCO DE REFERENCIA PARA LA SEGURIDAD

EN MONGODB, PARA IMPLEMENTAR EN LA MICRO Y

PEQUEÑA EMPRESA

Trabajo recepcional para obtener el grado de

MAESTRO EN SISTEMAS COMPUTACIONALES

Presenta: Licenciado Hugo Enrique De La Mora Carrillo

Director: Maestro Álvaro Iván Parres Peredo

Tlaquepaque, Jalisco.noviembre de 2017.

2
 AGRADECIMIENTOS
Deseo agradecer a mi familia por todo el apoyo recibido para llevar a cabo esta travesía de dos años con
el objetivo de obtener la satisfacción familiar y un grado académico nunca antes visto en nuestro seno
familiar.

Agradezco al CONACYT por haberme becado, ya que sin ello habría sido imposible haber realizado este
estudio, con el patrocinio reflejado en la beca número 591601 con el número de apoyo 424541 ha logrado
que un mexicano más incremente su conocimiento científico y lo pongo al servicio del país.

Agradezco al ITESO por la enseñanza recibida, así como el apoyo económico a través de la Beca con la
industria y a mi empresa CONTPAQi por apoyarme en tiempo y económicamente.

Agradezco a mi director de tesis Maestro Álvaro Iván Parres Peredo por la guía, apoyo y gran ayuda
otorgada a lo largo de este trabajo, agradecimientos también para la Doctora Mildreth Alcaraz Mejía por
su apoyo, consejo y guía en mi estancia en la maestría de sistemas computacionales y al resto de profesores
que impartieron su catedra durante este tiempo.

3
 DEDICATORIA
Esta obra está dedicada a mi familia por su apoyo incondicional durante las largas jornadas de
investigación y arduo trabajo.

Dedicado también al lector, que se tomará minutos de su valioso tiempo para navegar entre letras, párrafos
que han costado mucho tiempo y esfuerzo redactarlos.

4
 RESUMEN
Hoy en día con el avance de la tecnología, los riesgos de seguridad informática crecen de forma
exponencial a cada instante y se vuelve muy importante su atención en gobiernos, grandes y pequeñas
corporaciones, y en general todas las personas.

En este trabajo se propone un marco de referencia para la seguridad en bases de datos no relacionales
particularmente en MongoDB.

Se presentan tres grandes hitos:

• Políticas
a. Se refiere a lo que deseamos proteger y el porqué de ello.
b. Uso y limitaciones de los recursos.
c. Definición de violaciones y consecuencias de no cumplimiento.
• Configuración
a. Se refiere a configurar de forma correcta la base de datos para cuidar la confidencialidad,
integridad, autenticidad, no repudio, disponibilidad de los recursos y de la información,
consistencia, control de accesos y auditoria.
• Set de pruebas
a. La validación a través de pruebas de concepto de las políticas y de la configuración.

Con estas consideraciones se resuelve en gran medida el problema de seguridad de implementaciones en

bases de datos documentales específicamente MongoDB.

Se hace particular énfasis en la implementación en empresas pequeñas ya son las que generalmente no
cuentan con personal especializado y este marco de referencia ayuda a minimizar los riesgos que existen
debido a malas implementaciones, políticas y procedimientos.

5
 TABLA DE CONTENIDO
1. INTRODUCCIÓN ................................................................................................................................... 9

1.1. ANTECEDENTES ............................................................................................................................ 10

1.2. JUSTIFICACIÓN ............................................................................................................................. 11
1.3. PROBLEMA ................................................................................................................................... 12
1.4. OBJETIVOS ................................................................................................................................... 12
1.4.1. Objetivo General:................................................................................................................................ 12
1.4.2. Objetivos Específicos: ........................................................................................................................ 12

2. ESTADO DEL ARTE ............................................................................................................................ 13

2.1. SEGURIDAD EN BASES DE DATOS NOSQL..................................................................................... 13

2.2. PROBLEMAS DE SEGURIDAD EN UNA BD NOSQL ......................................................................... 13
2.3. NIVEL DE MADUREZ EN BD RELACIONALES Y NO RELACIONALES ................................................ 14
2.4. ENCRIPTACIÓN, EXTENDIENDO LA SEGURIDAD EN UNA BASE DE DATOS NOSQL ........................ 15

3. MARCO TEÓRICO/CONCEPTUAL ................................................................................................. 16

3.1. PRIMERAS BASES DE DATOS ........................................................................................................ 16

3.2. BASES DE DATOS .......................................................................................................................... 17
3.2.1. TIPOS Y USOS ................................................................................................................................ 17
3.3. MONGODB ................................................................................................................................... 18
3.3.1. BREVE HISTÓRICA, ESTRUCTURA Y DE MONGODB....................................................................... 18
3.4. SISTEMA DE GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN ......................................................... 19
3.4.1. GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN (ISO/IEC27001) ............................................ 19

4. PROPUESTA DE MARCO DE REFERENCIA PARA LA SEGURIDAD ..................................... 22

4.1. EVALUACIÓN PREVIA DE SEGURIDAD ........................................................................................... 22

4.2. IDENTIFICACIÓN DE DATOS SENSIBLES ......................................................................................... 23
4.2.1. INVENTARIO ................................................................................................................................. 23
4.3. SEGURIDAD GENERAL EN BASES DE DATOS .................................................................................. 23
4.4. MEDIDAS PARTICULARES DE MONGODB ..................................................................................... 26
4.5. MEJORA CONTINUA, EVALUACIÓN DEL MARCO DE REFERENCIA DE SEGURIDAD .......................... 30
4.6. ¿QUÉ NO CUBRE EL MARCO DE REFERENCIA DE SEGURIDAD? ...................................................... 30

5. RESULTADOS Y DISCUSIÓN............................................................................................................ 31

5.1. ESCENARIO DE IMPLEMENTACIÓN ................................................................................................ 31

5.2. RESULTADOS OBTENIDOS ............................................................................................................. 31
5.3. DISCUSIÓN ................................................................................................................................... 32

6. CONCLUSIONES .................................................................................................................................. 33

6.1. CONCLUSIONES ............................................................................................................................ 33

6.2. TRABAJO FUTURO ........................................................................................................................ 34

6
 LISTA DE FIGURAS
Figura 1. Arquitectura MongoDB [3]. ....................................................................................................... 18

7
 LISTA DE TABLAS
Tabla 1. Hallazgos en MongoDB [3]. ......................................................................................................... 13

8
 1. INTRODUCCIÓN
Dentro de la micro y pequeña empresa el almacenamiento de datos con herramientas hechas en casa
o por terceros sin la implementación adecuada en seguridad, son susceptibles a ser atacadas por
delincuentes cibernéticos con conocimientos, inclusive básicos, para afectar la continuidad del negocio,
robar o borrar información importante, por este motivo es indispensable elevar los niveles de seguridad
de dichas aplicaciones, políticas y procedimientos ya que la información de las empresas suele ser lo más
importante que poseen.

Al ser un negocio tan lucrativo está involucrado muchas veces el crimen organizado a gran escala,
también los cibercriminales son auspiciados por gobiernos y organizaciones privadas en busca de obtener
información de carácter ilegal.

La idea de este trabajo de grado surge al empalmar la realidad y vida profesional en un campo hasta
ahora poco explotado en la industria nacional de las micro y pequeñas empresas adentrándose en la
seguridad informática para robustecer las medidas que tienen para cuidar su información, por ello nos
expondremos en un marco de referencia de seguridad para bases de datos documentales particularizando
el estudio en MongoDB.

9
 1.1. Antecedentes
La seguridad en las bases de datos se define en base a tres grandes objetivos alrededor de la información:
1) la confidencialidad, 2) la integridad y 3) la disponibilidad. Siendo el cuidado de la información un tema
crítico dentro de las organizaciones por el gran valor que estas representan para ellas [1].

Actualmente existe un mayor reto entorno a la seguridad de las bases de datos debido a que existen muchos
servidores de bases de datos expuestos en internet por causa de una mala configuración, es muy común
que implementadores poco experimentados en temas tecnológicos recientes lleven a ambientes
productivos servidores y sistemas que no han pasado por una configuración adecuada en seguridad [1].

Dentro del mundo de Bases de datos (BD) se establecen diferencias entre sistemas relacionales y no
relaciones o también conocidas como NoSQL, siendo el primero el más popular, fácilmente identificado
por tener tablas, columnas y transacciones, el segundo en cambio se caracteriza por almacenar información
que pueden ser documentos, grafos, estructuras clave-valor principalmente, así Sethuraman [2] realiza un
análisis de seguridad en MongoDB una base de datos documental; Hadoop-Hbase, una base de datos
distribuida de información masiva; adicionalmente Oracle y MySQL dos bases de datos relacionales,
planteándose la pregunta: ¿Las bases de datos NoSQL son lo suficientemente seguras para soportar
aplicaciones de tecnologías de información al interior de las organizaciones? concluyendo que las BD
relaciones aparecen con mayores características de seguridad incorporada, mientras que las BD NoSQL,
al ser código abierto las analizadas, pueden usar implementaciones externas que podrían incrementar las
capacidades nativas de la confidencialidad, integridad y disponibilidad (CIA).

Dos de las bases de datos NoSQL más populares, MongoDB1 y Cassandra2, son analizadas en sus aspectos
de seguridad por Okman [3] encontrando problemas comunes en ambos sistemas, por ejemplo: 1) la falta
de soporte de encriptación de los archivos de datos, 2) débil autentificación entre servidores y entre el
cliente y el servidor, 3) poseen autorización simple, sin soportar un control basado en roles o una
autorización granular, 4) vulnerabilidades de inyección de SQL y 5) ataques de denegación de servicio.
Lior sugiere que las generaciones de sistemas de manejadores de BD necesitaran desarrollarse
considerablemente y mejorar con el fin de proveer seguridad para los datos sensibles que almacenen.

Debido a que la seguridad en las bases de datos no documentales no es un tema central de su diseño,
autores como Xingbang [4] proponen el uso de un middleware3 con el objetivo de encriptar los datos
dentro de MongoDB y así aumentar la confidencialidad de estos.

Por otro lado, Ajeet [5] nos propone un marco de referencia para asegurar la confidencialidad e integridad
de los datos, utilizando un sistema de compartir y ocultar. El sistema está dividido en 2 partes: 1) la zona
de confianza y 2) la zona sin confianza. El servidor de indexación y el propietario de datos se consideran
que están en la zona de confianza, mientras que el proveedor de servicios y los clientes en la zona sin

1
MongoDB, sistema de BD orientado a documentos.
2
CassandraDB, sistema distribuido de BD orientado a clave-valor.
3
Middleware, software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, o
paquetes de programas, redes, hardware y/o sistemas operativos.

10
confianza. Propone un esquema de compartir, secreto y limitado, se usa para distribuir los datos entre
servidores a través de índices cifrados, con cierta información secreta lo distribuye entre múltiples
entidades, logrando con este esquema simple incrementar la seguridad.

De manera similar a Lior, pero analizando otra base de datos Asadulla [6] menciona que Redis4 no es una
base de datos adecuada para trabajos empresariales y la presenta es una forma simple de llave-valor,
soporta todo tipo de estructuras de datos como variables, listas ligadas, arreglos, cadenas y colas, pero no
provee seguridad para los datos nativamente, cualquiera puede obtener el valor si sabe la llave. Para
agregar seguridad a un sistema que opera sobre esta base de datos propone: a) servicios de autentificación,
b) encriptación de servicios, c) seguridad para persistir los datos en blobs5. A través de este trabajo el
autor concluye que es posible implementar seguridad al sistema, lo anterior lo logra utilizando llaves
criptográficas simétricas que eliminan la necesidad de protocolos de intercambio, estos análisis nos ayudan
a afirmar que este tipo de bases de datos NoSQL centran su diseño arquitectónico en almacenar
información masiva y acceder a ella rápidamente y no en la seguridad.

Lo anterior nos invita a trabajar en el diseño de un marco de referencia para mejorar la seguridad dentro
de la implementación que comúnmente se realiza al utilizar MongoDB en el ámbito de la micro y pequeña
empresa dado que hemos observado importantes debilidades al revisar los antecedentes en esa base de
datos y otras similares cuya principal razón de ser no es la seguridad.

1.2. Justificación

La industria de la ciberdelincuencia está en pleno desarrollo, los beneficios que reporta son excelentes y
los riesgos que se corren son mínimos [7-8]. Según McAfee calcula, el costo anual de la ciberdelincuencia
en la economía global supera los 445 mil millones de dólares, cifra que incluye tanto las ganancias de los
delincuentes como los costos que suponen a las empresas la recuperación y la defensa. Las estimaciones
más conservadoras evalúan las pérdidas en 375 mil millones y según otras fuentes, podrían alcanzar los
575 mil millones. Esta cifra es superior a la renta nacional de la mayoría de los países y es equivalente a
entre el 0.5 y el 0.8 % de la renta mundial [9].

De igual manera la mala administración de las bases de datos alojadas en servicios en la nube, ha
provocado pérdidas a las organizaciones privadas y públicas. Un ejemplo de lo anterior es el caso del
acceso no autorizado a la base de datos del padrón electoral mexicano en 2016 [10].

A inicios de 2017 se publicó un ataque de ransomware que afectó a más de 27,000 servidores MongoDB
[11].

4
Redis, sistema de BD orientado a clave-valor en memoria, pero que opcionalmente puede ser usada como
una base de datos durable o persistente
5
Los BLOBS, son elementos utilizados en las bases de datos para almacenar datos de gran tamaño que
cambian de forma dinámica.

11
El incremento percibido en amenazas de seguridad ha aumentado significativamente, las coberturas
mediáticas son mayores y el acceso a la información se ha simplificado, el 34% piensa que una brecha es
algo que va a pasar, algo inevitable, los grandes riesgos de la información empresarial son el error humano
y el abuso de privilegios, el 65% de las empresas no puede determinar el abuso de privilegios de usuarios
debido al bajo nivel de monitoreo [12].

MongoDB es una base de datos que por defecto no incluye la seguridad básica, la mayoría de las Pymes
al no contar con personal especializado [13] suele priorizar la funcionalidad sobre la arquitectura y
seguridad, dejando grandes huecos en ambientes productivos.

1.3. Problema

Los problemas de seguridad en bases de datos NoSQL como MongoDB, han sido provocados por la falta
de conocimiento por parte de los administradores de bases de datos para asegurar la información, las
implementaciones con parámetros por defecto y la exposición a redes públicas sin los cuidados adecuados,
provocando que los datos almacenados estén expuestos a terceros no autorizados, provocando un alto
riesgo de compromiso con la información.

Tampoco se suelen seguir políticas y procedimientos adecuados referenciados en algún sistema de gestión
para la seguridad de la información.

1.4. Objetivos

1.4.1. Objetivo General:

Diseñar un marco de referencia que enuncie los lineamientos adecuados para incrementar la seguridad
de la base de datos no relacional, MongoDB, al interior de la micro y pequeña empresa.

1.4.2. Objetivos Específicos:

• Reducir los riesgos inherentes a seguridad de MongoDB en micro y pequeñas empresas.
• Realizar una prueba piloto demostrando la funcionalidad mejorada después de aplicar el marco
de referencia de seguridad.
• Redactar un marco de referencia de seguridad para MongoDB.

12
 2. ESTADO DEL ARTE
2.1. Seguridad en bases de datos NoSQL

La seguridad en las bases de datos ha sido abordada por algunos autores desde diferentes puntos de vista.
Autores como Okman [3] nos presentan los diversos problemas que tienen las bases de datos NoSQL o
Sethraman [2] dedica su trabajo a presentar un nivel de madurez para cada base de datos. En otro sentido
autores como Khan [6] nos hacen una propuesta de cómo implementar seguridad en un motor de bases de
datos específico.

2.2. Problemas de seguridad en una BD NoSQL

Okman [3] analiza a las bases de datos MongoDB y Cassandra, señalando los principales problemas y
características de seguridad en estos dos motores.

El autor menciona que en esta investigación hace falta la encriptación para los datos de los archivos,
menciona la debilidad de autentificación entre el cliente y los servidores, así como entre los propios
servidores, habla de la simplicidad en el manejo de roles, toca el tema de las vulnerabilidades de inyección
de SQL y de la denegación de servicio.

Un resumen de los hallazgos del autor y algunos consejos de seguridad se muestran en la Tabla 1, en la
cual se habla de información en reposo, autentificación para conexiones nativas, autorización para
conexiones nativas, auditoria, autentificación, autorización para conexiones RESTful, comunicación con
BD y ataques de inyección [3].
Tabla 1. Hallazgos en MongoDB [3].

# Categoría Estatus Recomendación

1 Información en reposo
2 Autentificación para
conexiones nativas
3 Autorización para conexiones
nativas
No encriptada
Disponible solo en
configuraciones no fragmentadas
(unsharded)
Lectura / Lectura-Escritura /
Niveles de administración, solo en
configuraciones no fragmentadas
Proteger con mecanismos a
nivel del SO
Habilitarla de ser posible,
requiere habilitar su
configuración
Habilitar de ser posible,
requiere habilitar
autentificación

13
 4 Auditoria
5 AAA (Autentificación,
autorización y auditoria) para
conexiones RESTful
6 Comunicación con BD
7 Ataques de inyección
No disponible en MongoDB N/A
Usuarios y permisos son Disponible si se configura
mantenidos externamente un proxy reverso
Encriptación no disponible N/A
Posible vía JavaScript o Verificar que la aplicación
concatenación de cadenas tenga razonable validación
de entrada

Por lo tanto, los principales problemas encontrados es la falta de soporte de encriptación para archivos de
datos, débil autentificación entre el cliente y los servidores, así como entre los propios servidores, simple
autorización sin soporte para control de acceso basado en roles (RBAC) o autentificación granular y
vulnerabilidad a inyección de SQL y denegación de servicio.

2.3. Nivel de madurez en BD relacionales y no relacionales

Sethuraman [4] propone la seguridad basada en la confidencialidad, integridad y disponibilidad (CIA),

dentro de su trabajo presenta un análisis de los motores de bases de y MongoDB, MySQL, Oracle y
Hadoop-HBase. Este análisis lo hace evaluando cada uno de los motores mencionados en diferentes
aspectos:

a) Confidencialidad a través del control de acceso o autentificación. MongoDB soporta acceso

basado en roles, la autentificación se realiza a través del mecanismo de verificación contra la
contraseña almacenada en la base de datos, Oracle maneja un control de acceso basado en los
privilegios asignados y granulado, al igual que MongoDB la autentificación es mediante la
contraseña almacenada en la base de datos; MySQL ofrece un acceso basado en los privilegios
que el usuario tiene en la base de datos, la autentificación es mediante usuario y contraseña, y
finalmente Hadoop brinda el control de acceso basado en roles a través de un tercero como
Cloudera Sentry.
b) Características extendidas de Confidencialidad. En MongoDB la autentificación puede hacerse
utilizando LDAP6, Kerberos7 o certificados X.509. La información puede encriptarse usando SSL
y certificados digitales. Por su parte en Oracle la autentificación puede ser mejorada usando
aplicaciones de terceros como LDAP, Kerberos, etc., de similar forma MySQL utiliza
mecanismos de autentificación externos como los ya mencionados Kerberos y LDAP, más
identificadores de usuario de Windows para autentificación. Finalmente, Hadoop puede usar
software de terceros como Cloudera para mejorar el control de acceso, la autentificación puede

6
LDAP, son las siglas de Lightweight Directory Access Protocol (en español Protocolo Ligero/Simplificado
de Acceso a Directorios) que hacen referencia a un protocolo a nivel de aplicación que permite el acceso a un
servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red.
7
Kerberos, es un protocolo de autenticación de redes de ordenador creado por el MIT que permite a dos
ordenadores en una red insegura demostrar su identidad mutuamente de manera segura.

14
 realizarse también con Kerberos, LDAP así mismo se puede encriptar con AES 256 y Cloudera
Navigator puede ser usado para el guardado seguro de llaves.
c) Encriptación de información. MongoDB permite que los datos pueden viajar encriptados
utilizando SSL o librerías de terceros como LUKS, IBM Guardium Data Encryption para datos
en tránsito. De la misma forma en Oracle los datos son encriptados usando SSL y certificados
X.509, soportando diversos algoritmos de encriptación como AES, DES y SHA1. En MySql los
datos son encriptados usando AES, DES y algoritmos de Hash como MD5 y SHA1. Finalmente,
Hadoop permite encriptar los datos usando AES 256.
d) Integridad y control de concurrencia. En MongoDB el control de concurrencia se hace presente
dando el acceso compartido a los lectores y el acceso exclusivo a los escritores. En Oracle el
mecanismo de bloqueo proporciona control de concurrencia, en MySql el control de concurrencia
se hace a través de bloqueos, mientras que Hadoop con su sistema de archivos admite a un único
actor escribiendo y a múltiples actores leyendo.
e) Integridad y sus restricciones. La base de datos Mongo soporta nulos, las colecciones en
MongoDB tienen un índice único que es similar a la llave primaria, en Oracle los valores nulos
pueden o no ser permitidos y con la restricción de clave única es seguro que no hay dos valores
iguales en la columna, MySQL ofrece valores nulos y no nulos, la clave primaria y la externa son
usadas para asegurarse que los valores en particular en una columna son únicos, Hadoop: soporta
nulos, HBase, la base de datos NoSQL de Hadoop, introduce una única forma de renglón llave
para dar unicidad a los datos almacenados en la base de datos.

2.4. Encriptación, extendiendo la seguridad en una Base de

Datos NoSQL

El trabajo de Asadulla [6], menciona que la base de datos NoSQL Redis no es adecuada para actividades
empresariales debido a sus debilidades en seguridad, en esta investigación el autor agrega seguridad a la
base de datos usando lo siguiente: a) servicio de autenticación y autorización, b) servicios de cifrado, c) la
seguridad de los datos persistentes.

Su trabajo consiste en la autentificación y autorización creando una llave que puede contener el usuario y
contraseña; encriptación de servicios, cualquier usuario que quiera acceder necesita estar registrado;
encriptación de variables y su contenido mediante AES8 simétrico y finalmente información persistente
y segura almacenada en la base de datos, guardando la última sesión en la que el usuario tuvo interacción
con la base de datos y al regresar continua su sesión.

Asadulla concluye que con su propuesta incrementa la seguridad usando una llave de criptografía simétrica
que elimina la necesidad de cualquier protocolo de intercambio de llaves, también la información de entre
sesiones están protegidas, es posible que diferentes usuarios pueden tener variables con el mismo nombre,
información persistente e información de red ambas están aseguradas. Así, el sistema propuesto extiende
las capacidades del sistema logrando una base de datos segura que puede ser utilizado en aplicaciones de
tiempo real afectando solo en milisegundos la obtención de información.

8
AES Estándar de encriptación avanzada

15
 3. MARCO
TEÓRICO/CONCEPTUAL
3.1. Primeras Bases de Datos

Para almacenar datos han existido varias formas a través de la historia [14-15] sus orígenes se remontan a
la antigüedad donde ya existían bibliotecas y toda clase de registros.

En 1884 Herman Hollerith diseña la máquina perforadora de tarjetas, después una máquina tabuladora,
basada en tarjetas perforadas, en la década de 1950 se inicia el trabajo con las cintas magnéticas, en la
década de 1960 bajaron los precios de las computadoras para que se pudiesen adquirir y hacer popular el
uso de los discos. En esta época también empezaron las primeras generaciones de bases de datos de red y
las bases de datos jerárquicas. Durante este tiempo también se unieron IBM y American Airlines para
crear SABRES, un sistema operativo que controlaba las reservas de vuelos, información de los pasajeros
y las transacciones, en 1963 en california se escuchó el terminó BD como un cúmulo de información
reunida o estructurada, más tarde, Charles Bachman creó un nuevo tipo de bases de datos y esto permitió
la creación de un estándar en los sistemas de bases de datos gracias a invención de nuevos lenguajes de
sistemas de información.

En la década de 1970 Frank Codd, aclaró el modelo relacional a la vez que publicó una serie de reglas
para los sistemas de datos relacionales, a raíz de esto nació la segunda generación de los Sistemas Gestores
de Bases de Datos. Gracias al trabajo de Codd, Larry Ellison desarrolló el Relational Software System,
aunque actualmente se conoce como Oracle Corporation, creando así un sistema de gestión de bases de
datos relacional con el nombre de la compañía, en los 80 se creó un lenguaje de consultas de acceso a
bases de datos que permite realizar consultas para recuperar información de interés de una base de datos
y realizar cambios de manera sencilla; aparte de examinar grandes cantidades de información y deja
detallar varios tipos de operaciones frente a la misma información, durante este tiempo SQL comenzó a
ser el modelo de la industria; las bases de datos relacionales con su sistema de tablas pudieron competir
con las bases jerárquicas y de red.

En los 90 investigaron las bases de datos orientadas en objetos. Han tenido bastante éxito a la hora de
ejecutar datos complejos en los terrenos donde las bases de datos relacionales no han podido desenvolverse

16
de manera eficaz. Así Microsoft creó herramientas como el Excel y Access, en esta época también, se
empezaron a incorporar nuevas expresiones regulares, consultas recursivas y algunas características
orientadas a objetos. Además, se creó la oportunidad de que SQL se pueda utilizar simultáneamente XML,
y se determina como importar y guardar datos XML en una base de datos SQL [16].

En 2007 la empresa 10gen la cual en 2013 pasó a llamarse MongoDB Inc., desarrolló una plataforma de
plataforma como servicio, en 2009 utilizando parte del código de la plataforma MongoDB fue lanzado
como un producto independiente, con licencia de código abierto [17].

3.2. Bases de datos

3.2.1. Tipos y usos

Los tipos más comunes de bases de datos son: a) relacionales, b) documentales, c) clave valor, d) grafos
y e) de columna, aunque existen muchas más las anteriores son las que gozan de mayor popularidad.

Las principales bases de datos y sus principales características se muestran a continuación, se enlistan de
acuerdo a su popularidad [18]:

1. Oracle, es un BD relacional, lanzada en 1980, su más reciente liberación fue en marzo 2017 la
versión 12.2.0.1, con licencia comercial, desarrollada en lenguaje C y C++, define estructuras en
memoria, maneja el principio de atomicidad, consistencia, aislamiento y durabilidad (ACID) en
transacciones [19-20].
2. MySQL, es un BD relacional, lanzada en 1995, su más reciente liberación fue en abril 2017 la
versión 5.7.18, con licencia de código abierto, desarrollada en lenguaje C y C++, maneja el
principio de atomicidad, consistencia, aislamiento y durabilidad (ACID) en transacciones [21],
[22].
3. SQL Server, es un BD relacional, lanzada en 1989, su más reciente liberación fue en mayo 2017
la versión 2016 sp1, con licencia comercial, desarrollada en lenguaje C y C++, maneja el principio
de atomicidad, consistencia, aislamiento y durabilidad (ACID) en transacciones [23].
4. PostgreSQL, es un BD relacional, lanzada en 1989, su más reciente liberación fue en mayo 2017
la versión 9.6.3, es de código abierto, desarrollada en lenguaje C, maneja el principio de
atomicidad, consistencia, aislamiento y durabilidad (ACID) en transacciones [24-25].
5. MongoDB, es un BD de almacenamiento de documentos, lanzada en 2009, su más reciente
liberación fue en abril 2017 la versión 3.4.4, es de código abierto, desarrollada en lenguaje C++,
maneja las transacciones con un simple documento, tiene concurrencia [26-27].
6. DB2, es un BD relacional, lanzada en 1983, su más reciente liberación fue en abril 2016 la versión
11.1, con licencia comercial, desarrollada en lenguaje C y C++, maneja el principio de atomicidad,
consistencia, aislamiento y durabilidad (ACID) en transacciones [28].

17
 3.3. MongoDB
3.3.1. Breve histórica, estructura y de MongoDB

El nombre de MongoBD proviene de homongosu que significa enorme, la base de datos es de código
abierto, guarda las estructuras de datos en documentos de formato ligero para el intercambio de datos
llamados BSON, los cuales son una representación binaria de estructuras de datos y mapas, son JSON
binarios.

El desarrollo de MongoDB empezó en 2007 en la empresa software 10gen inc., un par de años después en
2009 fue lanzado MongoDB como un producto independiente y finalmente en 2011 se lanzó la versión
1.4 que fue considera lista para producción.

Entre sus principales características destacan consultas AdHoc, indexación, replicación, balanceo de
carga, almacenamiento de archivos, agregación, fragmentación (sharding) y ejecución de JavaScript del
lado del servidor, sus problemas principales son: no asegura durabilidad, integridad, consistencia y
aislamiento en transacciones. Mongo está posicionado como la primera base de datos NoSQL y es la quinta
en general [18], utilizada por más de 2000 clientes importantes [29].

En la Figura 1. se muestra la arquitectura general de MongoDB [3], los shard servers son los que contienen
los datos, también se encuentran los config servers lo cuales contienen la información y ruta de ubicación
de los shard servers y finalmente los servidores llamados mongos los cuales son servidores mongos que
son los que reciben las peticiones de los clientes.

Figura 1. Arquitectura MongoDB [3].

18
 3.4. Sistema de Gestión de Seguridad de la Información
3.4.1. Gestión de la Seguridad de la Información
(ISO/IEC27001)
Un sistema de gestión de la seguridad de la información (SGSI) se utiliza para diseñar, implementar,
mantener procesos y políticas para gestionar eficientemente la accesibilidad de la información, buscando
asegurar la confidencialidad, integridad y disponibilidad de los activos reduciendo los riesgos de seguridad
detectados [30].

Se compone de:

• Definición de políticas
• Definición de alcance
• Identificación de riesgos
• Manejo de riesgos
• Selección de controles
• Definir reglas que se aplicarán

La ISO/IEC 27001 incorpora la metodología plan, do, check y act, la cual es un proceso metodológico
elemental aplicable en cualquier campo con el fin de asegurar la mejora continua, con el objetivo de aplicar
a un proceso una acción cíclica formada por cuatro pasos fundamentales [31]:

• Plan (planificar): evaluar riesgos de seguridad de la información y la selección de controles

adecuados.
• Do (hacer): implementación y operación de controles, procesos y procedimientos.
• Check (controlar): desempeño, medidas de proceso contra políticas, objetivos, prácticas y reportar
resultados para su revisión.
• Act (actuar): tomar acciones correctivas y preventivas, basada en los resultados de la auditoria interna
y otra información relevante para la mejora continua.

1. Plan: ¿cómo decido que hacer y en qué orden?

Edwards Deming afirma: “no basta con hace lo mejor posible, se debe saber qué hacer y luego hacerlo
mejor”, parte del plan debe incluir [32]:

a) Una política de seguridad, en la que se define el propósito, el alcance, roles y responsabilidades, algunas
categorías pueden ser, acceso remoto, protección de información sensible, protección del perímetro,
seguridad del servidor, administración de la configuración.

b) Los resultados del análisis de riesgos, se deben identificar los activos importantes y de esos activos
cuales tienen mayor riesgo para priorizar las prácticas de seguridad en el desarrollo, implementación y
operaciones.

c) La estrategia de seguridad y el plan, los temas generalmente son la estandarización de procedimientos

y procesos, el presupuesto de seguridad, las actividades de seguridad, roles y responsabilidades de
seguridad, competencias del equipo de seguridad.

19
d) Medidas de seguridad, “lo que se mide, se hace”, dependiendo de la organización se fijaran las métricas
de seguridad de información, servicios, aplicaciones, infraestructura, junto con los objetivos de negocio.

2. Hacer: ¿cómo lo hago?

a) Construir y mantener una red segura.

Instalar y mantener una configuración perimetral para proteger los datos. No utilizar valores
predeterminados para las contraseñas, configuraciones y otros parámetros de seguridad. Mantener un
inventario de todos los dispositivos, software y servicios.

b) Proteger los datos sensibles.

Proteger los datos almacenados. Cifrar la transmisión de datos confidenciales.

c) Mantener un programa de gestión de vulnerabilidades.

Usar y actualizar regularmente programas antivirus. Protegerse contra todas las formas de código
malicioso.

d) Implementar medidas de control de acceso fuertes.

Restringir el acceso a los datos. Restringir el acceso físico a datos confidenciales.

e) Regularmente monitorear y probar redes.

Dar seguimiento y monitoreo a los datos confidenciales. Probar regularmente los sistemas y procesos de
seguridad.

f) Mantener una política de seguridad de la información.

g) Desarrollar, desplegar y actualizar periódicamente algún nivel de sensibilización de seguridad.

h) Determinar e implementar un medio para medir la efectividad de las tareas.

i) Asegúrese de que los proveedores terceros implementen prácticas de seguridad adecuadas.

3. Controlar: ¿cómo verifico que lo que hice funcionó?

Esta pregunta se responde mediante el monitoreo, la medición, la revisión, la evaluación del desempeño
de la seguridad del sistema y se debe realizar periódicamente y como parte de las operaciones.

El aspecto más crítico de la fase controlar es definir de antemano lo que constituye el éxito y el desempeño
aceptable y luego asegurarse de que existen prácticas para recopilar y reportar estos criterios a aquellos
que estén en posición de actuar sobre los resultados.

4. Actuar: ¿cómo decido qué hacer a continuación?

En la fase de actuar, consiste en determinar la mejor manera de mantener el actual estado de seguridad, al
mismo tiempo que se adapta a los cambios y mejoras. Las acciones deben estar informadas por la política
de seguridad, los objetivos, las estrategias, los planes, los resultados de la evaluación de la fase de
verificación y el análisis de los eventos de seguridad.

Actuar a menudo comienza como una tarea reactiva, identificar las acciones correctivas críticas a corto
plazo que deben tomarse inmediatamente. A medida que el sistema y el estado de seguridad del software
se vuelven más estables, el personal puede concentrarse en medidas preventivas y proactivas. Las prácticas

20
centradas en la evaluación del riesgo que producen resultados confiables son uno de los métodos más
eficaces para determinar qué hacer a en consecuencia de esos resultados [33].

21
 4. PROPUESTA DE MARCO DE
REFERENCIA PARA LA
SEGURIDAD
El marco de referencia para la seguridad de MongoDB nos presenta una serie de lineamientos para mejorar
sustancialmente la seguridad, se enfoca tanto en medidas administrativas como técnicas.

El marco se encuentra dividido en: a) identificación de datos sensibles, b) medidas generales, como lo son:
seguridad del servidor, firewalls, software, aplicaciones, estaciones de trabajo, cuentas de administrador,
permisos, contraseñas, roles de usuario, datos sensibles, auditoria, respaldos, restauración, cifrado y
gestión de claves y c) medidas particulares de MongoDB, como los son: autentificación, control de acceso
basado en grupos, encriptación, instancia con usuario dedicado, permisos de conexión, opciones de
configuración y la seguridad de red.

4.1. Evaluación previa de seguridad

Lo primero que se deber realizar es obtener la línea base, por lo tanto, empezaremos por identificar
estándares de seguridad existentes, guías, políticas, procesos o procedimientos aplicables de forma
trasversal a todos los sectores de infraestructuras críticas de la base de datos Mongo.

Estos son los datos que tomaremos de línea base.

• Políticas y procedimientos de seguridad implementados.

• Control de acceso y autentificación.
• Control de acceso basado en funciones.
• Principio de menor privilegio.
• Comunicación cifrada.
• Datos en reposo cifrados.
• Exposición a la red.
• Bitácoras.
• Usuario utilizado para ejecución.
• Forma de ejecución de MongoDB.

22
 • Exposición a internet.
• Medidas perimetrales de seguridad.

Con los anteriores temas identificados procedemos a complementar las medidas de seguridad.

4.2. Identificación de datos sensibles

La primera parte que se debe comprender al implementar seguridad siempre es el inventario de activos
que se desean proteger, ya que no solo son confidenciales e importantes, sino que además una vulneración
de ellos implica problemas legales debido a las distintas leyes de protección de datos, sólo deben tener
acceso las personas o aplicaciones autorizadas, su no cumplimiento genera un riesgo mayor.

4.2.1. Inventario
El inventario de activos debe incluir activos lógicos y activos fiscos, ambos deben estar identificados en
un documento formal y a su vez dicho documento tiene mantenimiento periódico.

4.3. Seguridad general en Bases de datos

Estas son medidas generales recomendadas para cuidar la información en bases de datos [34].

1. Seguridad del servidor de bases de datos físicas

a. La máquina física que aloja una base de datos se encuentra en un entorno seguro,
bloqueado y supervisado.
b. Los servidores de aplicaciones y web no están alojados en la misma máquina que el
servidor de base de datos.
2. Firewalls para servidores de bases de datos
a. El servidor de base de datos se encuentra detrás de un firewall con reglas para denegar
todo el tráfico no autorizado.
b. El firewall del servidor de base de datos se abre sólo para aplicaciones específicas o
servidores web y las reglas de firewall no permiten el acceso directo del cliente.
Si el entorno de desarrollo o pruebas no puede cumplir este requisito, los datos sensibles
no deben almacenarse en el servidor de bases de datos de desarrollo o de pruebas, estos
deben llevar datos ficticios. La ofuscación de los datos no es suficiente.
c. Se debe probar periódicamente las reglas a través de escaneos de vulnerabilidades o
pruebas de penetración.
3. Software de la base de datos
a. La versión del software de base de datos está actualmente soportada por el proveedor o
proyecto de código abierto.
b. Todos los servicios o funciones no utilizados o innecesarios de la base de datos se quitan
o se apagan.
c. Se eliminan las cuentas predeterminadas innecesarias, o bien se cambian las contraseñas
de las predeterminadas.

23
 d. No se utilizan contraseñas nulas y se eliminan los archivos temporales del proceso de
instalación que pueden contener contraseñas.
e. Se deben instalar todos los parches de seguridad actuales. Se debe planificar la
implementación de los parches de seguridad de manera oportuna (primero en ambiente
de pruebas).
4. Aplicaciones
a. Los servidores de aplicaciones o webs que reciben datos sensibles están protegidos de
manera proporcional a las medidas de seguridad del sistema de origen.
b. Todos los servidores, aplicaciones y herramientas que acceden a la base de datos están
documentados.
c. Los archivos de configuración (web.config, app.config, etc.) y el código fuente están
protegidos y sólo accesibles por las cuentas requeridas y por personas autorizadas.
d. El código de las aplicaciones se revisa para evitar vulnerabilidades de inyección de SQL.
5. Estaciones de trabajo de usuario
Si a los usuarios se les permite tener información sensible en sus máquinas.
a. Se deben cumplir los estándares de seguridad en sus equipos de trabajo.
b. Sus máquinas deben estar protegidas por protectores de pantalla. Los usuarios entienden
el requisito de bloquear sus estaciones de trabajo al salir de su lugar.
c. La contraseña para ingresar a su equipo se debe cambiarse al menos cada 3 meses.
d. Los datos sensibles en la máquina del usuario están cifrados.
e. Los datos sensibles no son almacenados en dispositivos transportables (usb, cd, etc.) que
no estén cifrados.
f. Los datos sensibles nunca se envían por correo electrónico sin cifrar.
g. Los datos sensibles que ya no son necesarios se eliminan rutinariamente.
Para cifrar se recomiendan esquemas como PGP – llaves públicas y privadas.
6. Cuentas de administrador, permisos y contraseñas
a. En un deploy los DBAs entienden su responsabilidad de revisar todos los cambios
solicitados para validar que la seguridad de los datos no se vea comprometida.
b. Las cuentas de administrador se proporcionan a la menor cantidad personas posibles y
solo cuando es plenamente justificado.
c. Todos los desarrolladores, SysAdmins, DBAs y proveedores han firmado un acuerdo de
no divulgación.
d. Las cuentas de administrador son únicas y no compartidas en un grupo
7. Roles de usuario en la base de datos
a. Existe un procedimiento documentado para otorgar accesos a la BD.
b. A los usuarios se les conceden los permisos mínimos necesarios, los permisos se otorgan
a roles o grupos, no se otorgan directamente a los usuarios.
c. Las contraseñas son fuertes y se cambian periódicamente, no se almacenan, si se llegan
a almacenar se cifran.
d. Las cuentas que no tienen permisos de administrador, no deben tener privilegios para
otorgar accesos a ningún ambiente que tenga información sensible.
e. Las cuentas de administrador son bloqueadas después de 5 intentos fallidos.
f. Los DBAs generan reportes de cuentas con privilegios elevados de forma trimestral.

24
 g. Un reporte con todos los roles, usuarios y sus accesos es proporcionado al propietario de
datos por los DBAs al menos dos veces por año.
8. Datos sensibles
a. Solo los datos sensibles que son necesarios para la función del negocio se guardan en la
BD.
b. Es recomendable purgar la información histórica que no se necesita.
c. Los datos sensibles solo están en producción, siempre que es posible.
d. Se aplican funciones de hash a los elementos de datos sensibles antes de almacenar si los
datos sólo son necesarios para fines de coincidencia (generalmente contraseñas).
e. Los datos sensibles en entornos que no son de producción se mantienen con los mismos
estándares de seguridad que en producción. En caso de que los entornos que no son de
producción no tengan el mismo estándar de seguridad deben codificarse utilizando
algoritmos estándares de la industria. La ofuscación de datos no es suficiente.
f. Los programas que modifican o leen información sensible están documentados.

9. Auditoría de bases de datos

a. Todos los inicios de sesión para el sistema operativo y los servidores de bases de datos,
con éxito o sin éxito, se registran. Estos registros se conservan durante al menos un año.
b. Los objetos de base de datos con datos sensibles tienen la auditoría activada cuando es
técnicamente posible.
c. Los registros de auditoría son revisados periódicamente. Este proceso de revisión está
documentado.
d. Las cuentas que se bloquean debido a intentos fallidos de inicio de sesión en la base de
datos activan una notificación automática a los administradores de seguridad.
10. Copia de seguridad y recuperación de bases de datos
a. Los procedimientos de copia de seguridad y recuperación están documentados, probados
y validados.
b. Los tiempos de retención de copias de seguridad están documentados y son suficientes
para cumplir con los requisitos de reanudación del negocio.
11. Cifrado de base de datos y gestión de claves
a. Los datos sensibles se cifran durante la transmisión a través de la red utilizando medidas
de encriptación lo suficientemente fuertes como para minimizar el riesgo de exposición
de los datos si se interceptan.
b. Si se implementa el cifrado a nivel de base de datos para datos sensibles, se documentan
los procedimientos para la administración segura de claves. Nota: Se recomienda que
todas las capas de aplicación (red, aplicación, equipo de usuario) ya estén cifradas antes
de cifrar la base de datos. El cifrado de la base de datos no es un sustituto de ninguno de
los requisitos anteriores.
c. Los procedimientos de administración de claves para descifrar copias de seguridad están
documentados y disponibles para más de una persona.

25
 4.4. Medidas particulares de MongoDB

1. Autentificación

La autentificación es el proceso de verificación de la identidad de un cliente. Cuando se habilita el control

de acceso, es decir, la autorización, MongoDB requiere que todos los clientes se autentiquen para
determinar su acceso.

Aunque la autenticación y la autorización están estrechamente conectadas, la autenticación es distinta de

la autorización.

• La autenticación verifica la identidad de un usuario.

• La autorización determina el acceso del usuario verificado a los recursos y operaciones.

Métodos de autenticación, para autenticar un usuario, MongoDB proporciona el método db.auth().

Mongo soporta varios mecanismos de autentificación, SCRAM-SHA-1 (Salted Challenge Response

Authentication Mechanism, Secure Hash Algorithm), certificados x.509, LDAP (Lightweight Directory
Access Protocol) Proxy y Kerberos.

Habilitar la autentificación

Habilitar el control de acceso en una implementación de MongoDB implica incluir la autenticación, lo que
obliga a los usuarios a identificarse. Al acceder a una implementación de MongoDB que tenga habilitado
el control de acceso, los usuarios sólo pueden realizar acciones determinadas por sus funciones, el proceso
se describe en el apéndice A.

2. Control de acceso basado en roles

Crear roles que definan el acceso exacto que un conjunto de necesidades de los usuarios. Se debe seguir
el principio de menor privilegios. Al crear los usuarios y asignarles únicamente los roles que necesitan
para realizar sus operaciones. Un usuario puede ser una persona o una aplicación cliente, el proceso de
crear los roles se describe en el apéndice B.

Estos son los roles principales disponibles en MongoDB, cabe señalar que pueden personalizarse
combinaciones.

Roles de usuario

Read: proporciona la capacidad de leer datos de todas las colecciones que no son del sistema y de las
siguientes colecciones del sistema: system.indexes, system.js y system.namespaces.

ReadWrite: proporciona todos los privilegios del rol de lectura además de la capacidad de modificar
datos de todas las colecciones que no son del sistema y de la colección system.js.

26
 Roles de administrador

dbAdmin: tiene privilegios para realizar cualquier acción administrativa en la base de datos.

userAdmin: proporciona la capacidad de crear y modificar roles y usuarios en la base de datos actual.
Este rol también proporciona indirectamente acceso de superusuario a la base de datos. El rol userAdmin
permite a los usuarios otorgar a cualquier usuario cualquier privilegio, incluyendo ellos mismos.

dbOwner: el rol dbOwner puede realizar cualquier acción administrativa en la base de datos. Este rol
combina los privilegios otorgados por las funciones readWrite, dbAdmin y userAdmin.

Roles de administración de Cluster

clusterAdmin: provee el acceso mayor para la administración de clusters, combina el rol de

clusterManger, clusterMonitor y hostManger, adicionalmente la acción de dropDatabase.

clusterManager: proporciona acciones de administración y supervisión en el clúster. Un usuario con esta

función puede acceder a las bases de datos de configuración y locales.

clusterMonitor: proporciona acceso de solo lectura a las herramientas de monitoreo.

hostManager: proporciona la habilidad de monitorear y administrar servidores.

Roles de respaldo y restauración

Backup: proporciona los mínimos privilegios para hacer un respaldo.

Restore: proporciona los mínimos privilegios para restaurar un respaldo.

Roles de todas las bases de datos

ReadAnyDatabase: proporciona acceso de lectura a todas las bases de datos.

ReadWriteAnyDatabase: proporciona acceso de lectura y escritura a todas las bases de datos.

UserAdminAnyDatabase: proporciona el mismo acceso que proporciona userAdmin, excepto que se

aplica a todas las bases de datos local y config del clúster.

DbAdminAnyDatabase: tiene privilegios para realizar cualquier acción administrativa en cualquier base
de datos.

Roles de super usuario

Root: otorga todos los permisos, no puede cambiar colecciones de sistema.

Roles internos

System: MongoDB asigna este rol a objetos de sistema, este rol no debe asignarse a humanos o
aplicaciones.

27
 3. Encriptación

Encriptación en movimiento

Se debe configurar MongoDB para usar TLS / SSL para todas las conexiones entrantes y salientes. Se
debe utilizar TLS / SSL para cifrar la comunicación entre los componentes de mongo, así como entre todas
las aplicaciones.

Para su uso en producción, la implementación de MongoDB debe utilizar certificados válidos generados
y firmados por una autoridad de certificación. Se puede generar y mantener una autoridad de certificación
independiente o utilizar certificados generados por un proveedor de TLS / SSL de terceros.

Antes de poder utilizar TLS / SSL, hay que tener un archivo.pem que contenga un certificado de clave
pública y su clave privada asociada.

Con MongoDB se pueden utilizar certificados emitidos por entidades certificadoras o autofirmados, ambos
encriptan el canal, con los segundos no hay validación de la identidad del servidor, esto provoca que no
se pueda espiar en la conexión, pero deja susceptibilidad al ataque de hombre en el medio, el proceso se
describe en el apéndice C.

Encriptación en reposo

El cifrado en reposo, cuando se utiliza junto con el cifrado de transporte y las buenas políticas de seguridad
que protegen las cuentas, contraseñas y claves de cifrado relevantes, puede ayudar a garantizar el
cumplimiento de las normas de seguridad y privacidad, incluyendo estándares internacionales como
HIPAA, PCI-DSS y FERPA.

El motor de almacenamiento encriptado aparece en la versión 3.2 Enterprise, con ello MongoDB encripta
archivos de datos que solo con la llave de desencriptación se pueden decodificar, existen alternativas a lo
anterior, por ejemplo, guardium-data de IBM.

La encriptación de datos en reposo se puede resolver con cualquiera de las siguientes opciones:

1. Cifrar toda la unidad.

2. Cifrar archivos individuales o bases de datos en el disco.
3. Cifrar documentos completos (filas en el lenguaje de SQL) o atributos individuales (columnas en el
lenguaje de SQL) en el nivel de aplicación.

El cifrado de datos en reposo se puede resolver con cualquiera o todos los siguientes métodos: a) Cifrar
todo el volumen, b) Cifrar sólo los archivos de base de datos, c) Cifrar en la aplicación, por la sencillez
que representa, en este marco de referencia recomendamos cifrar desde la aplicación.

4. Bitácoras

MongoDB Enterprise incluye la capacidad de generar auditorías para instancias. La instalación de

auditorías permite a los administradores y usuarios realizar un seguimiento de la actividad del sistema para
implementaciones con múltiples usuarios y aplicaciones, en el apéndice D se puede observar su
habilitación.

28
Hay una alternativa gratuita a la versión Enterprise, se llama Percona server para MongoDB y la
configuración es similar.

El registro de auditoría de MongoDB proporciona una descripción detallada de lo que sucedió

exactamente. El registro de auditoría de Percona contiene menos de información, pero debería ser
suficiente para la mayoría de los análisis que se realicen después de ocurrida una vulneración. Usar el
registro de auditoria para análisis forense es bueno, aunque lo ideal es prevenir para no llegar a necesitarlo.

Otro propósito para el registro de auditoría es ver las tendencias que ocurren. Un buen ejemplo sería
comprobar la tasa de intentos fallidos de autenticación y si esto excede un cierto umbral, actuar sobre él.
Dependiendo de la situación, las medidas adoptadas podrían diferir. Una de las acciones podría ser
bloquear automáticamente la dirección IP de la que provienen las peticiones, pero en otro caso, podría
consultar con el usuario sobre por qué se olvidó la contraseña. Realmente depende del caso y del entorno
en el que esté trabajando.

5. Instancia, con usuario dedicado

Se debe ejecutar los procesos de MongoDB con una cuenta de usuario de sistema operativo dedicada. La
cuenta debe tener permisos para acceder a los datos, pero no de permisos innecesarios.

6. Restricciones de acceso

Es importante limitar la ejecución de MongoDB en un entorno de red de confianza y limite las interfaces
en las que las instancias de MongoDB escuchan las conexiones entrantes. Permitir que sólo los clientes de
confianza accedan a las interfaces de red y los puertos en los que MongoDB instancias están disponibles,
en el apéndice E se puede observar la configuración necesaria para restringir los accesos.

7. Ejecutar MongoDB con opciones de configuración segura

MongoDB admite la ejecución de código JavaScript para ciertas operaciones del lado del servidor como
mapReduce, group y where. Si no se utilizan estas operaciones, deben deshabilitarse las secuencias de
comandos del lado del servidor mediante la opción --noscripting en la línea de comandos.

Dejar estos protocolos desactivados, a menos que se requiera para compatibilidad con versiones anteriores:
net.http.enabled, net.http.JSONPEnabled y net.http.RESTInterfaceEnabled.

8. Seguridad en red

Para restringir la exposición a MongoDB, debe configurarse un firewall para controlar el acceso a los
sistemas MongoDB. El uso de VPN también puede proporcionar una forma segura de acceso.

29
 4.5. Mejora continua, evaluación del marco de referencia de
Seguridad

El marco de referencia contempla medidas que por sí mismas permanecen con vigencia en el tiempo, ya
que por definición deben actualizarse constantemente sin embargo es recomendable revisar su vigencia de
forma semestral para adecuarlo a las nuevas vulnerabilidades y mejoras en seguridad que correspondan.

4.6. ¿Qué no cubre el marco de referencia de Seguridad?

El marco de referencia no contempla medidas detalladas de configuración de dispositivos adicionales

como firewalls, identificadores de intrusos entre otros.

Si bien es cierto que cubre muchos aspectos, tampoco está enfocado a conseguir certificaciones tipo ISO
27001 o similares.

30
5. RESULTADOS Y DISCUSIÓN

5.1. Escenario de implementación

Este marco de referencia fue implementado en una micro empresa y en una pequeña empresa con
proyectos de MongoDB.

5.2. Resultados obtenidos

En la micro empresa se empezó a implementar, pero se detuvo para privilegiar la funcionalidad, el
proyecto consistía en montar una pequeña base de datos en una ambiente nube, durante 6 meses el enfoque
fue que el proyecto funcionará, una vez funcionando se liberó el producto.

Después de liberado, con todos los riesgos asumidos, se empezó a trabajar en los puntos propuestos por
este marco de referencia logrando implementar varios de ellos: inventario y respaldo, seguridad del
servidor de bases de datos físicas, firewalls para servidores de bases de datos, cuentas de administrador,
permisos y contraseñas, datos sensibles, copia de seguridad y recuperación de bases de datos, cifrado de
base de datos y gestión de claves, autentificación, control de acceso basado en roles, encriptación,
instancia, con usuario dedicado, restricciones de acceso, ejecución con configuración segura, seguridad en
la red.

No implementados aún: software de la base de datos, aplicaciones, estaciones de trabajo de usuario, roles
de usuario en la base de datos, auditoría de bases de datos

El proyecto en la pequeña empresa está en proceso, ya que decidieron implementar una base de datos
relacional por compatibilidad con el mercado, se planea en un futuro llevar a cabo una implementación
con MongoDB, pero no se ve cercano por la cantidad de funcionalidad que se tiene que migrar. En esta
empresa la implementación del marco de referencia sólo cubrió la identificación de activos y el
conocimiento de forma general del marco.

En un futuro cercano se medirán las mejoras de seguridad en varias micro empresas generadas a partir de
la incisión de un corporativo que seguirán este marco de referencia.

31
 5.3. Discusión
En las empresas pequeñas está claro que la urgencia es el tema de todos los días y generalmente la máxima
prioridad es la funcional sobre la arquitectura y la funcionalidad, recientemente la concientización ha
avanzado en temas de seguridad, gracias a los ataques masivos que ha habido y a la cobertura mediática
que han recibido, aun así, el camión por recorrer todavía es grande. La percepción sigue siendo que hasta
que no seas víctima no te proteges y sigue quedando para el final o una etapa dos implementar medidas
de seguridad, aunque tal vez ya sea demasiado tarde.

32
 6. CONCLUSIONES
6.1. Conclusiones
Existen algunos trabajos relacionados a marcos de referencia de seguridad, como por ejemplo existe un
marco de referencia utilizado por las grandes empresas como el SDL cuyos grandes objetivos son la
confidencialidad, integridad, autentificación y disponibilidad [35] pero va enfocado al desarrollo general
de software. También la organización para estándares internacionales (ISO) y la comisión electrotécnica
internacional (IEC) ISO / IEC 27034 proporciona una guía para ayudar a las organizaciones en la
integración de la seguridad en los procesos utilizados para la gestión de sus aplicaciones. ISO / IEC 27034-
1: 2011 presenta una visión general de seguridad a través de la gestión, introduce definiciones, conceptos,
principios y procesos que intervienen en la seguridad de aplicaciones [14]. Sin embargo, hay poco o nulo
trabajo enfocado a la micro y pequeña empresa, ya que estas no cuentan en su generalidad con especialistas
y sigue siendo hoy en día, la seguridad informática de las bases de datos NoSQL, un tema poco explorado
en este medio, por eso este trabajo particulariza el enfoque en seguridad en MongoDB, una Base de Datos
Documental.

MongoDB es una base de datos para las aplicaciones actuales, innovadora, rápidamente puede estar en
ambientes productivos, globalmente escalable y barata para operar. En este trabajo exploramos la
seguridad de MongoDB concluyendo que siguiendo las recomendaciones descritas sobre habilitar control
de acceso y robustecer la autentificación, configurar control de acceso basado en roles, comunicación
encriptada, encriptar los datos sensibles, limitar la exposición de la red, auditorias del sistema, entre otros,
robustecen la seguridad. Seguir las medidas recomendadas en este marco de referencia incrementan
sustancialmente la seguridad de los datos, sin embargo, requiere un cambio de cultura en los operadores,
tiene un costo ya que lleva tiempo su planificación, implantación y mantenimiento, las empresas que
deseen utilizarlo deberán hacer un análisis previo de la importancia que tenga su información y tomar la
decisión de que tanto la quieren proteger, marcar una estrategia firme de seguimiento e implementación.

El primer objetivo de este trabajo fue reducir los riesgos inherentes a seguridad de MongoDB en micro y
pequeñas empresas, la primera recomendación se realiza en la implementación de un sistema de gestión
de seguridad de la información (descrito en la sección 3.4 de este trabajo) centrado en el ciclo de Deming
(plan, hacer, controlar y actuar), después (en la sección 4) se propone una evaluación previa de seguridad
(sección 4.1), la identificación de datos sensibles (en la sección 4.2), una completa serie de

33
recomendaciones para base de datos (sección 4.3) y finalmente una extensiva sección de medidas
particulares para MongoDB (sección 4.4).

El segundo objetivo fue realizar una prueba piloto demostrando la funcionalidad mejorada después de
aplicar el marco de referencia de seguridad, se realizó un análisis de riesgos comparativo con la situación
antes y después, encontrando una disminución relevante e importante en los puntos que se abordaron,
mismos que se refieren a: respaldos, firewalls para servidores de bases de datos, cuentas de administrador,
permisos, copias de seguridad, cifrado y controles de acceso, demostrando así la efectividad del marco de
referencia propuesto.

El tercer objetivo redactar un marco de referencia de seguridad para MongoDB, se cumplió exitosamente
ya que incluimos de forma destacada, la recomendación de implementación de un sistema de gestión, la
autentificación de usuarios, el control de acceso a la BD basado en roles, la encriptación de datos en
movimiento, reposo, bitácoras e instalar mongoDB con usuario dedicado entre muchos otros puntos
mencionados en el capítulo 4.

6.2. Trabajo Futuro

Es altamente recomendable terminar una implantación completa de todos los puntos mencionados,
cuantificar el costo en tiempo y monetario, medir la operaciónٖ y mantenimiento para obtener el costo de
llévalo a cabo.

34
 BIBLIOGRAFÍA
[1] A. Basta and M. Zgola, Data Base Security, 1st ed. Boston, MA: Cengage Learning, 2011.
[2] S. Srinivas and A. Nair, "Security maturity in NoSQL databases - are they secure enough to haul
the modern IT applications?," 2015 International Conference on Advances in Computing,
Communications and Informatics (ICACCI), Kochi, 2015, pp. 739-744.
[3] L. Okman, N. Gal-Oz, Y. Gonen, E. Gudes and J. Abramov, "Security Issues in NoSQL
Databases," 2011IEEE 10th International Conference on Trust, Security and Privacy in
Computing and Communications, Changsha, 2011, pp. 541-547.
[4] Xingbang Tian, Baohua Huang and Min Wu, "A transparent middleware for encrypting data in
MongoDB," 2014 IEEE Workshop on Electronics, Computer and Applications, Ottawa, ON,
2014, pp. 906-909.
[5] A. R. Pathak and B. Padmavathi, "A secure threshold secret sharing framework for database
outsourcing," 2014 IEEE International Conference on Advanced Communications, Control and
Computing Technologies, Ramanathapuram, 2014, pp. 1642-1649.
[6] Asadulla Khan Zaki and Indiramma M., "A novel redis security extension for NoSQL database
using authentication and encryption," 2015 IEEE International Conference on Electrical,
Computer and Communication Technologies (ICECCT), Coimbatore, 2015, pp. 1-6.
[7] W. Gragido, Blackhatonomics. Amsterdam: Syngress, 2013.
[8] Alorie Gilbert (2004, Ago). Ecommerce turn 10. After a decade, even your mom buys books
online. But are secure transactions secure enough yet? [documento en línea]. Disponible:
http://www.cnet.com/news/e-commerce-turns-10
[9] McAfee (2014), Pérdidas netas: estimación del costo global de la ciberdelincuencia
[documento en línea]. Disponible: http://www.mcafee.com/mx/resources/reports/rp-economic-
impact-cybercrime2-summary.pdf
[10] Nayeli Cortés (2016, Abr). MC subió padrón a Amazon; un hacker lo atacó, justifica su líder
[documento en línea]. Disponible: http://www.elfinanciero.com.mx/nacional/mc-reconoce-que-
subio-lista-nominal-a-nube-de-amazon.html
[11] ABC (2017). Ransomware: Over 27,000 databases of MongoDB attacked in a day; many other
still vulnerable [documento en línea]. Disponible: http://www.abc.es/tecnologia/redes/abci-
enorme-ataque-ransomware-secuestra-32000-servidores-mongodb-201701102153_noticia.html
[12] Oracle (2014) DBA – Security Super Hero [documento en línea]. Disponible:
https://go.oracle.com/LP=6327?elqCampaignId=14504&src1=eV:NW:PT:&src2=SecurityNews
letter
[13] L. Pavón. Financiamiento a las microempresas y las pymes en México. Santiago de Chile:
Cepal, 2010.
[14] ISO/IEC 27034-1:2011 (2011, Nov) Information technology -- Security techniques --
Application security -- Part 1: Overview and concepts [documento en línea]. Disponible:
http://www.iso.org/iso/catalogue_detail.htm?csnumber=44378
[15] Błaż ewicz, W. Kubiak, T. Morzy and M. Rusinkiewicz, Handbook on Data Management in
Information Systems. Berlin, Heidelberg: Springer Berlin Heidelberg, 2003.

35
[16] A. Silberschatz, H. Korth and S. Sudarshan, Fundamentos de bases de datos. Madrid:
MacGraw-Hill, 2003.
[17] Gigaom (2013). 10gen embraces what it created, becomes MongoDB Inc. [documento en
línea]. Disponible: https://gigaom.com/2013/08/27/10gen-embraces-what-it-created-becomes-
mongodb-inc
[18] Solid IT (2018). DB-Engines Ranking [documento en línea]. Disponible: https://db-
engines.com/en/ranking
[19] Oracle (2017). Oracle página oficial [documento en línea]. Disponible:
http://www.oracle.com/database
[20] Documentación Oracle (2017). Database documentation [documento en línea]. Disponible:
http://docs.oracle.com/en/database/database.html
[21] MySQL (2017). MySQL página oficial [documento en línea]. Disponible: https://
www.mysql.com
[22] Documentación MySQL (2017). Dabase documentation [documento en línea]. Disponible:
http://dev.mysql.com/doc
[23] SQLServer (2017). SQLServer página oficial [documento en línea] 2017. Disponible:
https://www.microsoft.com/en-us/sql-server
[24] Postgres (2017). Postgres página oficial [documento en línea] 2017. Disponible
https://www.postgresql.org
[25] Postgres (2017). Database documentation [documento en línea] 2017. Disponible:
https://www.postgresql.org/docs/manuals
[26] Microsoft (2017). Microsoft página oficial [documento en línea] 2017. Disponible:
www.microsoft.com/en-us/sql-server
[27] MongoDB (2017). Database Documentation [documento en línea]. Disponible:
https://docs.mongodb.com/manual
[28] DB2 (2017). DB2 página oficial [documento en línea]. Disponible:
https://www.ibm.com/analytics/us/en/technology/db2/db2-linux-unix-windows.html
[29] Mongo (2017). Flexible enough to fit any industry. [documento en línea]. Disponible:
https://www.mongodb.com/who-uses-mongodb
[30] A. Calder, ISO27001. Ely, Cambridgeshire, U.K: IT Governance Pub, 2008.
[31] A. Andrés and L. Gómez, Guía de aplicación de la norma UNE-ISO/IEC 27001 sobre
seguridad en sistemas de información para pymes. Madrid: AENOR, 2009.
[32] M. Gutiérrez, Administrar para la calidad. México: Limusa, 2013.
[33] CERT de Estados Unidos (2013). CERT página oficial [documento en línea]. Disponible:
https://www.us-cert.gov/bsi/articles/best-practices/deployment-and-operations/plan-do-check-
act
[34] Universidad de Berkley (2017). Database hardening best practices [documento en línea].
Disponible: https://security.berkeley.edu/resources/best-practices-how-articles/database-
hardening-best-practices
[35] J. Ransome and A. Misra, Core software security: security at the source. Boca Ratón, FL: CRC
Press, 2014.

36
 APÉNDICE A. Autentificación en MongoDB
A continuación, el proceso de habilitar la autentificación en MongoDB.

Se crear el usuario administrador

use admin
db.createUser(
{
user: " admin_mongo",
pwd: " your password",
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

a) Verificar que ha sido creado

db.auth("admin_mongo", "your password")

db.getUsers()

b) Actualizar el archivo de configuración

Se debe agregar auth=true y reiniciar el servicio para que tenga efecto

logpath=c:\data\log\mongod.log

dbpath=c:\data\db

auth=true

c) Crear usuarios adicionales, con la autentificación habilitada

use test

db.createUser(

user: "myTester",

pwd: "xyz123",

37
 roles: [ { role: "readWrite", db: "test" },

{ role: "read", db: "reporting" } ]

d) Conectarse y autentificarse como myTester

use test

db.auth("myTester", "xyz123" )

e) Insertar una colección con el usuario myTester

Al tener privilegios de escritura y lectura puede ejecutar lo siguiente

db.foo.insert( { x: 1, y: 1 } )

APÉNDICE B. Crear roles MongoDB

a) Conectarse a MongoDB con privilegios

Por ejemplo:

Mongo –port 27017 -u admin_mongo -p ‘your password’ --authenticationDatabase ‘admin’

Ese usuario creado previamente tiene privilegios para crear roles en admin y en otras bases de datos.

a) Creamos un nuevo usuario que sí puede acceder a cualquier base de datos

db.createUser({user:'herminia', pwd:'chufas', roles: ['readWriteAnyDatabase']})

Crear un usuario 'aniceto' que solo tenga acceso de lectura y escritura a la base de datos repuestos, y solo
de lectura a la base de datos de clientes.
Para ello, el administrador debe escribir:

db.createUser({user:'aniceto', pwd:'regalices',
roles: [{role:'readWrite', db:'repuestos'}, {role:'read', db:'clientes'}]})

b) Crear un rol, por ejemplo, ManageOpRole tiene privilegios que actúan en varias bases de
datos, así como en el recurso de clúster. Como tal, debe crearse el rol en la base de datos de
admin.

use admin
db.createRole(
{

38
 role: "manageOpRole",
privileges: [
{ resource: { cluster: true }, actions: [ "killop", "inprog" ] },
{ resource: { db: "", collection: "" }, actions: [ "killCursors" ] }
],
roles: []
}
)
c) Para ver los roles de un usuario
use myDB
db.getUser("myUser")
...
"roles" : [
{ "role" : "readWrite", "db" : "accounts" },
{ "role" : "read", "db" : "myDB" },
{ "role" : "read", "db" : "products" },
{ "role" : "read", "db" : "sales" }
]

APÉNDICE C. Encriptación en movimiento

Para propósitos de prueba en un sistema Unix se puede realizar lo siguiente

cd /etc/ssl/
openssl req -newkey rsa:2048 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout
mongodb-cert.key

Esta operación genera un nuevo certificado autofirmado sin frase de contraseña válida por 365 días. Una
vez que tenga el certificado, concatene el certificado y la clave privada en un archivo.pem, como en el
ejemplo siguiente:

cat mongodb-cert.key mongodb-cert.crt > mongodb.pem

mongodb.pem se utilizará como archivo PEM, mongodb-cert.key es el archivo de clave privada y

mongodb-cert.crt es un archivo de certificado que también se puede usar como archivo de CA. Se
necesitarán los tres.

Es necesario copiar estos archivos en su carpeta / etc / ssl / que es donde pertenecen. Ahora abrimos
nuestro archivo de configuración de MongoDB

sudo vi /etc/mongod.conf

y se modifican las interfaces

# network interfaces
net:
port: 27019

39
 #bindIp: 127.0.0.1 # asumimos tráfico externo, por eso lo encriptamos.
ssl:
mode: requireSSL
PEMKeyFile: /etc/ssl/mongodb.pem
# PEMKeyPassword: password
#CAFile: /etc/ssl/mongodb-cert.crt
#disabledProtocols: TLS1_0,TLS1_1

Como siempre hay que reiniciar

sudo service mongod restart

En caso de error, podemos verlos corriendo lo siguiente manualmente

sudo mongod --config /etc/mongod.conf

mongo --ssl --sslAllowInvalidHostnames –sslAllowInvalidCertificates

Después habilitamos el CAFile del mongod.conf y ejecutamos lo siguiente

mongo --ssl --sslAllowInvalidHostnames --sslCAFile /etc/ssl/mongodb-ca.crt --

sslPEMKeyFile /etc/ssl/mongodb.pem

APÉNDICE D. Habilitación de auditoria

En la versión Enterprise bastaría con hacer lo siguiente en el archivo de configuración:

auditLog:
destination: file
format: JSON
path: /var/lib/mongodb/auditLog.json

APÉNDICE E. Restricción de accesos

Se establece en el archivo /etc/mongod.conf con net.bindIp en 127.0.0.1 para permitir solo el acceso de
sí mismo o la ip que corresponda, para más de una ip se separan con comas bindIp = [127.0.0.1,
192.168.184.155, 96.88.169.145]

APÉNDICE F. Términos generales de seguridad informática

CERT: equipo de respuesta a emergencias de seguridad.

40
Objetivos de una prueba de penetración: evadir las medidas de seguridad existentes para extraer
información sensible a la que no se debería tener acceso, determinar si es posible provocar una
denegación de servicio en redes y aplicaciones, detectar vulnerabilidades no conocidas.

Caja Negra: no se dispone de información interna

Caja Blanca: total información sobre el sistema a auditar.

Caja gris: conocimiento parcial del sistema.

OWASP: organización sin ánimo de lucro orientada a desarrollar proyectos de código abierto para
mejorar la seguridad informática.

NIST: Instituto de estándares internacionales y tecnología perteneciente al departamento de comercio de

los estados unidos [8].

SQLInjection: Ataques a sitios web a través de sentencias de SQL.

Cross site scripting: Ataques a sitios web a través de javascript.

Firewall: Sistema defensivo perimetral para minimizar el tráfico peligroso a través de puertos,
protocolos y en algunos casos a nivel de análisis de paquetes.

IPS: Sistema de prevención de intrusos, son sistemas que se encarga de monitorizar los paquetes que
viajan por la red. Se fundamentan en base de datos de firmas públicas que se van generando por el paso
del tiempo y por otro lado personalizadas por el administrador de IPS.

WAF: Parecido al IPS, pero con el enfoque de aplicaciones web, lo que se captura en un formulario será
analizado con base a firmas almacenadas en el WAF enfocadas a aplicaciones web.

41