Esquemas de seguridad en bases de datos NoSQL.pdf

Bases de Datos NoSQL

1. Esquemas de seguridad en bases de datos
NoSQL
1. Introducción a las bases de datos NoSQL
Las bases de datos NoSQL, en vez de guardar los datos en tablas, lo hacen en documentos y colecciones
(MongoDB, CouchDB), columnas (Cassandra) o grafos (Neo4j). Una de las principales desventajas que tiene
es la seguridad. Un primer método para asegurar una base de datos NoSQL es a través del Firewall. Toda
base de datos NoSQL necesita algún puerto para escuchar las peticiones y conexiones de autenticación,
requiere un puerto que sea accesible por la aplicación. La primera medida que realiza el firewall para
asegurar la base de datos es restringir el acceso a una dirección IP determinada. Es decir, según la IP del
cliente que desee acceder a la base de datos, mediante el firewall, solo se permitirá el acceso a una IP y
puerto concreto.
El próximo paso es la utilización de certificados de unión de conexiones seguras (SSL), para cifrar todas
las conexiones con la base de datos. Actualmente, la capa de servicios de seguridad (SSL) es el método
más común para el tráfico de datos segurizados entre diferentes puntos, incluso dentro de los mismos
sistemas fÃ​sicos, normalmente dispositivos de almacenamiento NAS (Archivos) y SAN (Bloques). Para
acceder a la base de datos de manera segura y guardar los datos también de manera encriptada, se utiliza
el SSL. SSL se divide en dos capas, la de certificados de seguridad y la de enlace de conexión segura. En el
caso de Cassandra, existen dos métodos de autenticación, el primero es una fácil configuración de
autenticación de contraseña básica, para que esta opción sea efectiva, esta opción debe estar
activada.
1.1. Definición y caracterÃ​sticas principales de las bases de datos NoSQL
En 2009, Stonebraker publicó un artÃ​culo llamado "La Jugada de los 10 Grandes: A lo que hay detrás del
renacimiento de las bases de datos paralelas y ¿Qué será de las bases de datos relacionales?". Según
este artÃ​culo, las bases de datos NoSQL no estaban diseñadas para reemplazar a las bases de datos
relacionales. Pero desde hace 4 años, conocemos que éstas, las denominadas NewSQL, pueden llegar a
ofrecer niveles de concurrencia e inserción mayores a las de las bases de datos relacionales sea cual sea su
modelo relacional. Dicho artÃ​culo analiza las caracterÃ​sticas de NoSQL, y las clasifica en 4 grupos: 1)
SCHEMA-LESS: Capacidad para definir y usar la información sin definir rÃ​gidamente su esquema. 2)
DISTRIBUTED AND FAULT TOLERANT: Los datos se almacenan y procesan a través de varios servidores. 3)
EVENTUAL CONSISTENCY: Los datos no tienen por qué ser consistentes en el tiempo, pero se garantiza que
si no se insertan más operaciones desde el último momento en el que los datos se tenÃ​an por
consistentes, al eliminar la posibilidad de concurrencia, la base de datos vuelve a un estado "consistente". 4)
BIGDATA. Abarca desde las técnicas para gestionar volúmenes de información gigantes (HADOOP), como
las que permiten explotar ("minerÃ​a de datos") y gestionar el fenómeno de la información distribuida entre
los internautas ("cloud computing").
Los pilares que sustentan estas bases de datos son su distribución y escalabilidad, por lo que la seguridad
enfocada a estas bases de datos no puede hacerse de manera aislada. Las caracterÃ​sticas principales de
estas herramientas plataformas de bases de datos, incluidas las que ofrecen servicios NoSQL son: a) Base de
datos pueden gestionar estructura y tipos de datos tan flexibles como lo permitan el hardware (RAM, disco,
...), ni los algoritmos (rendimiento repartido, algoritmos de distribución de datos entre nodos si la bds es
distribuida, ...), b) Utilizan almacenamiento RAM para acceder a los datos directamente desde memoria y
espacios de almacenamientos de alta velocidad para almacenar los datos. c) Aprovechan la conexión a red
para realizar comunicaciones de manera distribuida a otros equipos.
2. Importancia de la seguridad en bases de datos
La importancia de la seguridad en la información es cada vez mayor en el contexto actual, donde la
tecnologÃ​a permite la generación y acceso a enormes cantidades de datos. Es por eso que, al utilizar una
base de datos, hay que tener en cuenta caracterÃ​sticas importantes como la confiabilidad, integridad y
disponibilidad. EspecÃ​ficamente, en el contexto de la transferencia de la administración de las bases de
datos a grandes proveedores de servicios en la nube o a grandes infraestructuras/empresas que confÃ​an la
información de sus clientes en medios de almacenamiento multiservicio, aparecen los mecanismos
postulados en las bases de datos NoSQL, como un pilar fundamental para el manejo de la seguridad.
Los datos, como eslabón de información del núcleo de la compañÃ​a, crean de manera colateral un flujo
de información para la toma de decisiones que van a ser insumo para diferentes partes del mercado a la
compañÃ​a. Estos datos cada vez son más deseados y sustraÃ​dos por personal ajeno a la compañÃ​a
mediante ataques informáticos. Los grandes distribuidores e información externos basan la información
aportada por el cliente en una protección de seguridad mediante mecanismos postulados a las bases de
datos NoSQL (mejor conocidos como sistemas o motores). Por ejemplo, la base de datos NoSQL MongoDB

2. posee una capa de seguridad la cual es un agregado especialmente al producto, debido a que al ser una
base de datos NoSQL, el paradigma relacionase hace que en la parte del gestor de base de datos se deba
añadir algún método consecuente a las caracterÃ​sticas ágiles, horizontales y distribuidas de MongoDB
para contener el infortunio de la ausencia de seguridad en un motor de bases de datos no estructurado.
2.1. Riesgos y amenazas en la gestión de bases de datos
2.1.1. Protección frente a accesos no deseados A pesar de que los proveedores incluyen medidas básicas
de seguridad como la posibilidad de que solo los usuarios miembros de unos grupos especÃ​ficos puedan leer
o modificar un documento o de que solo puedan consultar su progresión, la necesidad de salvaguardar el
acceso, tanto fÃ​sico como lógico, de información sensible hace imprescindible implementar medidas más
avanzadas para proteger tanto los datos como el sistema completo. En este sentido, dependerá de las
caracterÃ​sticas y de la realización de una evaluación de riesgos y de la categorización de la información
la implementación o no de mecanismos avanzados de protección. En cualquier caso, algunas de las
medidas disponibles son el despliegue de cortafuegos, certificados, encriptación, autenticación o el uso de
tokens, entre otros.
2.1.2. Verificación de la integridad Sobre la base de comprobaciones de integridad de los datos
almacenados, MongoDB permite hacer firmas de los documentos como propiedad del documento (aunque
dicha propiedad se reserva el propósito especÃ​fico de implementaciones internas de MongoDB). Consiste
en un hash de un hash de un documento de acuerdo con la especificación de documentos BSON. Al realizar
la colección de firma, el principal objetivo es proporcionar un mecanismo de detección de corrupción de
datos tanto fÃ​sicos como de transmisión y evitar alteraciones no autorizadas mediante mecanismos o
atacantes que fueren capaces de destrabar los mecanismos de control sofisticados implementados. Aunque
también proporciona información de la firma, generalmente debe entenderse como un hash de los
campos básicos de un documento y, por lo tanto, solo debe proporcionarse como una herramienta de
diagnóstico o evaluación en lugar de un mecanismo de seguridad en sÃ​ misma.
3. Conceptos clave de seguridad en bases de datos
Las bases de datos NoSQL disponen de mecanismos de seguridad muy diferentes a los de las bases de datos
relacionales, y estas diferencias tienen su reflejo en la manera de definir esquemas de seguridad en bases
de datos NoSQL. Como se discutirá en la Sección 1, las bases de datos o bases de datos de documentos
NoSQL tienden a equipararse con los modelos de bases de datos de entidades relacionadas y sus permisos a
los de las bases de datos relacionales, mientras que las bases de datos estáticas/dinámicas NoSQL se
configurarán de forma mucho más orientada al servicio.
En NoSQL, una base de datos se divide en colecciones no relacionadas entre sÃ​ con una alta orientación al
almacenamiento agrupado por campos clave. Cada colección incluirá un número indeterminado de
documentos que a su vez constarán de campos clave y valores. Un documento es el análogo en clave-
valor al registro en bases de datos relacionales. Al igual que en el caso relacional, cada campo de un registro
puede tener asociado un conjunto de restricciones. En el caso de bases de datos NoSQL, los documentos de
una misma colección podrán tener un conjunto de campos diferente. La definición de estas restricciones
sobre los campos formará el esquema de la base de datos: los posibles valores de un campo, los conjuntos
de datos en los que se divide una clave y todas aquellas restricciones que se establezcan sobre el campo
según el tipo de base de datos NoSQL que nos encontremos.
3.1. Autenticación y autorización en bases de datos
Es necesario conocer las diferencias entre sin autenticación y sin autorización para entender cómo
interactúan estas caracterÃ​sticas cuando se combinan. La autenticación valida la identificación, mientras
que la autorización valida los privilegios o derechos de acceso que posee un determinado sujeto sobre un
determinado recurso.
Un esquema con autenticación y sin autorización permitirá el acceso a un recurso especÃ​fico una vez
verificada la identidad del usuario. Un esquema sin autenticación y sin autorización proporcionará acceso
irrestricto a un recurso determinado a cualquier usuario que intente acceder al recurso.
El objetivo de proveer autenticación es que el sistema de bases de datos (DBMS, Database Management
System) sea capaz de identificar la identidad del cliente que intenta acceder a esta base de datos, los datos
o las operaciones.
De acuerdo a Mary L. Slaney de Cornell University, un esquema de autenticación clásico se comunica con
el sistema de autenticación, generalmente al nivel del sistema operativo de la base de datos, basándose
en una polÃ​tica preestablecida. En algunos sistemas de bases de datos todas o la mayorÃ​a de las
operaciones son imputadas a "procedimientos almacenados", "triggers" o "funciones escalares". Sin
embargo, en la generalidad de los casos las aplicaciones ejercen operaciones directamente en un esquema
de autenticación que se comunica con el sistema de autenticación, generalmente al nivel del sistema

3. operativo de la base de datos, basándose en una polÃ​tica preestablecida.
La autorización establece a qué sujetos se les permiten las operaciones en los objetos de la base de
datos. AsÃ​, en un sistema de venta de tiquetes, hasta que un tiquete no está vendido, el usuario que
cuestionado es autenticable orienta la forma en la que él o ella intenta marcar el objeto inactiveeligible de
que muestres los detalles del tique. Después de haber sido vendido, sin embargo, el cliente que compró
el billete deberÃ​a ser el único eligiendo que muestre la información del billete.
4. Esquemas de seguridad en bases de datos NoSQL
Las bases de datos NoSQL son especialmente interesantes por lo que se conoce como flexibilidad
esquemática, es decir, cuanto más distribución o latencia ofrece una BD NoSQL, menos información se
tiene (de partida, tendrÃ​a que ser remunerada) sobre el diseño del esquema de datos. En el caso de las BD
NoSQL, dado que el esquema no está forzado, sino que pueden ser tanto fijos o semánticos (generalmente,
estructurando la CLAVE), como con flexibilidad en el diseño de los campos almacenados, fruto
frecuentemente de la capacidad de almacenar información en formato JSON, XML, en lugar de formato de
campo-clave predefinido, el riesgo de una BD NoSQL a priori serÃ​a lo que tradicionalmente se conoce como
testing sin proyecto, vale decir, no tener una idea clara y desarrollada (modelo del sistema) de lo que
almacena la implementación fÃ​sica que aloja la información. A priori lo que se salta del desarrollo de
seguridad sobre las BD NoSQL parece no cuadra dentro de los cubes, pero la tendencia actual, marcada por
los servicios Cloud, es la de ir a un mayor nivel de abstracción (el cube con menos cubitos) que facilite la
migración de servicios Cloud a distintas tecnologÃ​as de bases de datos, con lo que el nivel de riesgo sea
nulo para BD NoSQL en un escenario real, al depender, entre otros factores, del tipo de arquitectura NoSQL
que se esté utilizando, el conocimiento sobre los riesgos de seguridad tanto por parte de los
desarrolladores de aplicaciones como por los administradores de bases de datos y los conocimientos sobre
metodologÃ​as y herramientas de pruebas de seguridad especÃ​ficas para plataformas NoSQL. Los resultados,
sin embargo, se contradicen con la conclusión de limitar el riesgo a no tener un modelo del sistema claro
antes del testeo, que estarÃ​a basada en que cuanto menos se conozca algo, más difÃ​cil será protegerlo
con eficacia, sobre todo, si se habla de seguridad de datos. Por otra parte, sÃ​ parece claro a dÃ​a de hoy el
conflicto entre la elaboración de una estructura esquemática de datos fija en una BBDD en la que no se
pueden anticipar ni saber al completo todas y cada una de las consultas que se vayan a lanzar, de forma que
la alternativa contemporáneo a una arquitectura NoSQL por el requerido nivel de concurrencia de escritura
y veracidad/durabilidad de las transacciones, reside en una arquitectura con plistores (bases de datos
planas) y bases de datos no relacionales fuertemente denormalizadas. Gracias a este cambio fuimos
capaces de localizar dónde ya se usaban las denormalizaciones (verificando que estaban correctamente
aplicadas) y comenzar a desarrollar las primeras partes con una base de datos NoSQL debido a garantizar
que en la nueva arquitectura se devuelvan sólo los resultados que se vayan a mostrar, obteniendo asÃ​ un
rendimiento deseado de la aplicación.
4.1. Modelos de seguridad en bases de datos NoSQL
Existe una gran variedad de modelos de seguridad (esquemas de seguridad) implementados en las bases de
datos NoSQL según las propias caracterÃ​sticas y funcionalidades soportadas por cada una de las distintas
ramas de las mismas. En este apartado se explicarán los modelos más seguros, los modelos
recomendados, los modelos habituales, los modelos NO seguros y otros. Además se recomendará el
modelo de seguridad ideal en función del riesgo que está dispuesto a asumir el usuario de la base de
datos, por lo que al final de este apartado se hará un análisis del estado del arte con apartado especÃ​fico
de criterios de análisis.
- Modelos más seguros: Orientadas a documentos, Clave-valor y Almacenamiento de tipos de datos (Value
types). La implementación de log de comandos (command-log) en la que se mantiene herramientas, como:
W*R*, H*M*, MDT/MPT. - Modelo recomendado: Orientado a la columna. La implementación de log de
comandos (command-log) en la que se mantiene herramientas, como: H*M*. - Modelos habituales:
Orientadas al árbol. Modelos No fiables: Clave-valor, Columnares, de Tipo documental y de Tipo tabla. Con
logs de comandos (commandlog), NI Virtuales. Por tanto, los elementos susceptibles de seguridad siempre
pueden ser agrupados en cuatro: lo que hay que proteger, la infraestructura de seguridad en sÃ​, los sujetos
que tienen que interactuar con la infraestructura de seguridad y, sobre todo, el nivel de seguridad que se
debe aplicar.
Teddy R. (2014) añade que, en cualquier polÃ​tica de seguridad relativa a bases de datos, esas cuatro
funciones abordadas anteriormente deben contemplarse de forma integral, pero además "deberá
establecerse la forma en que se auditará el comportamiento del sistema, de modo que sea posible, ante
cualquier situación anómala y siempre desde el escenario de un ataque o intento de ataque detectado,
informar a las personas responsables de la seguridad para que puedan reaccionar ante la amenaza
correctamente."
5. Métodos de autenticación y autorización en bases de

4. datos NoSQL
5.1.1. MongoDB
MongoDB scalability is a system that allows adapting the security of a NoSQL database to its specific
environment and usage. Although its security is simple, it is extensible and meets the needs of extensive
data deployments and on-site operations in mobile applications, among other scenarios. MongoDB offers
great flexibility and fine-grained control in assigning roles and permissions to users, being able to assign
different roles and permissions to the same database based on its collections or to different individual
sensors based on the operations they can access. Roles and permissions can also be defined for different
databases. If used within an application deployed on a web service platform, authentication services specific
to that platform can be used, or both users and necessary roles can be defined in the MongoDB schema
since they are used for MongoDB or sensor roles (containers) individually.
5.1.2. Apache Cassandra
Apache Cassandra 6 has a security framework that provides authentication and authorization across multiple
nodes. It provides the same security model for operations on entire databases as well as at the row or
column level. Since version 2.0, Cassandra allows users to authenticate using passwords and has a system
for creating external authentication entries (LDAP and other directory services), which allows authentication
to be provided using other agreed-upon processes. Authorization controls are based on the role of the
authenticated user and the clauses of the CQL commands that request permissions are validated before
executing these queries for the different resources of the corresponding node.
5.1. Control de acceso basado en roles
Roles dentro del dominio securitario. AsÃ​, los usuarios asociados a un cierto rol adquieren unas
determinadas capacidades, normalmente asociadas a la operación concreta, que les permitirán realizar
determinados privilegios. Estos dos enfoques son complementarios y aseguran que únicamente los usuarios
autorizados puedan acceder a los recursos que les estén permitidos.
Hay que tener en cuenta que, al establecer roles, se separa el modelo de control de acceso del modelo de
negocio: esto puede suponer una falta de flexibilidad para adaptar el sistema a futuros cambios en el
negocio, y también, sobre todo si no se ha realizado un análisis completo del dominio de seguridad, la
categorización de usuarios y roles puede ser incorrecta y se producirán problemas de escalabilidad al
crecer el número de roles. Todo esto implica que tenga que configurarse demasiados controladores, lo que
hará el sistema difÃ​cil de mantener y administrar.
Para salvar las limitaciones presentadas por el modelo basado en roles, en el caso de ciertos sistemas NoSQL
como MongoDB, podemos emplear una técnica en la que se asigna a los propios documentos la propiedad
que siempre tienen y se comprueba esa propiedad para calcular la lista de operaciones disponibles.
Mediante este mecanismo, se consigue un rol más abstracto que las propias operaciones, lo que implica que
se minimizan en número estos roles en el sistema. A través de estas propiedades podemos asegurar que
un usuario únicamente tiene permisos para acceder a ciertos recursos, o a ciertos resultados dentro del
recurso, sin importar si alguna operación concreta realizada en este se ajustará a lo permitido.
6. Técnicas de encriptación en bases de datos NoSQL
Esquemas de seguridad en bases de datos NoSQL y se propusieron técnicas para proteger bases de datos
NoSQL. Existen varias bases de datos NoSQL CMS (Document-Based): CouchDB. CouchDB ofrece también
RDF seguros, modificación al acceso de mensajes HTTP y limitaciones por cookie. Por otro lado, CouchDB
permite con el uso de send dell, cuyo mapa en hs canales, es un proyecto de CouchDB y MySQL permiten
crear consultas de sesión basada en bases de datos de respuesta SQL.
Técnicas de encriptación en bases de datos NoSQL consisten en transformar la base de datos original en
un archivo que no sea posible de entender por personas no autorizadas. De esta forma, se requiere atribuir
la clave a un conjunto de ventanas. Una vez que se haya establecido el vencimiento, el refuse is in system is
in isna is in system to execute the original ini he spent in the query gave a result, sacrifice the confirmation
about the absence of information without explicit access, we need to create another table. For example, a
patient is refuse to0 to a doctor and the patient is from the same beneficiary group of the wants to consult
the patient would not; Need hospital, but that must access the type of query to get the information; at least
three PRPs are required.
6.1. Encriptación de datos en reposo y en tránsito
Cada base de datos NoSQL ofrece distintas opciones de encriptación, pero por lo general todas brindan las
opciones de encriptar los datos que almacenan en reposo y de encriptar las comunicaciones con sus
servicios. Por ejemplo, Couchbase es una base de datos NoSQL para documentos que admite encriptación

5. de datos en tránsito mediante SSL. En su versión de pago, admite también la encriptación de los
documentos almacenados en reposo. Al igual que otras bases de datos NoSQL, permite utilizar claves de
encriptación de forma personalizada. DynamoDB, la base de datos NoSQL de Amazon, viene encriptada en
reposo por defecto. Tal y como explican en su documentación, "Never provision or manage encryption keys.
Amazon DynamoDB automatically encrypts all data at rest." Igual que sucede con Couchbase, permite
definir claves de encriptación personalizadas, y se encuentran completamente aisladas de los recursos de
DynamoDB.
En el caso de Elasticsearch, es posible encriptar todos los datos almacenados en sus nodos, los datos
transferidos en Elasticsearch, la comunicación entre los nodos de un clúster y las comunicaciones entre los
componentes de la pila de Elasticsearch. Además, los certificados necesarios para llevar a cabo estos
cifrados se tramitan automáticamente. Cassandra, por su parte, permite usar el protocolo nativo de
Cassandra con las comunicaciones entre nodos y con los clientes. Es posible garantizar la autenticación de
las claves de acceso de lectura y escritura con elópticointerior, y opcionalmente, también las
comunicaciones con SSL. En el caso de MongoDB, se encuentra autenticado por defecto con los servicios con
SSL, y encriptado en reposo en el caso de los problemas desplegados.
7. AuditorÃ​a y monitoreo en bases de datos NoSQL
En la mayorÃ​a de las bases de datos NoSQL se carece de la capacidad de auditorÃ​a, lo que conlleva la falta
de trazabilidad de accesos y vistas a los datos almacenados en las mismas, de tal forma que las acciones
parecen no dejar huella. Entre las bases de datos no relacionales, este es uno de los aspectos menos
desarrollados.
AsÃ​, los sistemas NoSQL están pensados para operar en ambientes controlados, es decir, donde el usuario
desconfÃ​a y no considera necesario proteger su información almacenada. Un aspecto crÃ​ticamente
relevante, que está directamente relacionado con la seguridad, es la capacidad de monitoreo de la base de
datos para detectar los diferentes tipos de amenazas.
En teorÃ​a, deberÃ​an ser todas las bases de datos NoSQL las que tengan la capacidad para gestionar el
acceso de los usuarios a la base de datos y a los datos almacenados en la misma, el manejo de los permisos
necesarios por parte de un usuario o aplicación. Analizar la capacidad de encriptación de los datos en la
base de datos, tanto en su almacenamiento como en tránsito. Comprobación de la capacidad de la base de
datos NoSQL para monitorizar y someternos a la auditorÃ​a las diferentes actividades llevadas a cabo por los
usuarios. Aprovisionamiento de capacidades de "defensa activa" contra las amenazas analizadas. Analizar la
inspección de la base de datos, asÃ​ como la monitorización en tiempo real para detectar y prevenir
intrusiones en la base de datos.
7.1. Importancia de la auditorÃ​a en la seguridad de bases de datos
Finalmente, habrÃ​a que hacerse la siguiente pregunta: ¿Es acaso necesaria la auditorÃ​a en una base de
datos? La auditorÃ​a es una técnica probada mediante la cual es posible asegurarse de la calidad del
funcionamiento y de los controles de seguridad implantados en un sistema de información. Es el proceso
que, mediante una evaluación objetiva de la evidencia sobre un sistema, permite concluir el grado de
cumplimiento respecto de un cierto conjunto de metas predefinidas. Dicho de otra forma, la auditorÃ​a
permite asegurar que el sistema funciona como habÃ​a sido diseñado y que no presenta debilidades que
pudiesen ser aprovechadas para cometer actos ilÃ​citos.
En un sistema de información, el evento que desencadena el conjunto de procesos necesarios para que la
auditorÃ​a pueda tener lugar se denomina evento audit-able (audit event). Es precisamente la creación de
dicho evento audit-able el hecho que se desea controlar, de forma que si posteriormente la auditorÃ​a
descubre que ha habido un ataque o que los objetivos del evento no se han cumplido, el auditor podrá
revisar los correspondientes registros (registros de auditorÃ​a o logs) con el objetivo de establecer qué fue
lo que aconteció en el sistema en el momento de la ocurrencia del evento audit-able. En el mundo de las
bases de datos, este concepto de evento audit-able se traslada a los registros de auditorÃ​a (log records,
journal records, etc.), que permiten realizar un seguimiento de las operaciones realizadas sobre los objetos
gestionados por el sistema de base de datos.
8. Casos de estudio y ejemplos prácticos
Amazon DynamoDB ha sido uno de los primeros servicios NoSQL escogidos por grandes compañÃ​as y ha
sido principalmente utilizado en aplicaciones web y/o móviles. Para este caso de estudio, vamos a
considerar una aplicación web en la que el usuario introduce sus credenciales de acceso. La información
normalmente confidencial del usuario constará de un e-mail, contraseña (además del nombre completo
si se desea) y su último acceso.
Amazon Web Services (AWS) tiene un producto llamado Amazon Cognito en el que se pueden alojar los dos
factores para la autenticación de usuarios. Para asegurar los datos de usuarios seleccionaremos el

6. pequeño proveedor AES de encryption directa que proporciona DynamoDB. Una vez usados los métodos
de marcar el control de accesos de la polÃ​tica de control de acceso. Una de las mejores caracterÃ​sticas de
Amazon Cognito es el control de "sincronización" que tiene sobre DynamoDB. Al insertar o eliminar datos de
código (cliente) en la base de datos, los cambios serán enviados a DynamoDB con la polÃ​tica de control de
acceso, pero una vez sea eliminado/desactivado el usuario en Cognito, el usuario se desvinculará de la base
de datos de manera automática.
MongoDB provee de una polÃ​tica de control de acceso.
Amazon Web Services (AWS) generalmente ha presentado problemas para el manejo de datos estructurados
o tabulares. Amazon Aurora surge como una oportunidad de administrar redundancia y sistemas de
replicación de datos para alta disponibilidad y protección de la base de datos central. Es por esto que
Amazon Aurora presenta la posibilidad de realizar réplicas de lectura con la polÃ​tica de seguridad
implementada en una base de datos duplicada. Para Amazon Web Services (AWS), al crear el ejemplo de
polÃ​tica básica, consideraremos un ejemplo básico con un motor Percona (similar a MySQL). Una vez
preparadas las polÃ​ticas de replicación y seguridad de datos, se establecerá una conexión de servidor
entre DynamoDB y la seguridad de datos.
8.1. Implementación de esquemas de seguridad en bases de datos NoSQL
Esta sección resume la situación de implementación de esquemas de seguridad en los sistemas de bases
de datos NoSQL más extendidos explicados con anterioridad, presentando los mecanismos de seguridad
que ofrecen a fecha de cierre de esta revisión y algunas de sus limitaciones. Finalmente se proporciona un
conjunto de destrezas y experiencias recopiladas durante el proceso para facilitar a futuros profesionales la
implementación de esquemas de seguridad en bases de datos NoSQL empresariales.
MongoDB ofrece el modelo de seguridad con usuarios que tiene UNIX y Windows. Un usuario es un string
que se utiliza para acceder a MongoDB, utilizando como contraseña el resultado de aplicar una función
hash SHA-1 a un string que se denomina seed. Cuando se arranca el proceso de MongoDB se crea un
usuario, llamado admin, asignado a un rol que es capaz de autenticarse y autorizado a diferentes
operaciones. El resto de usuarios, que tengan un rol de lectura/escritura sobre ciertas colecciones, etc., lo
tienen que crear los administradores de tal colección (Management). A la hora de configurar las bases de
datos de los servidores de MongoDB (shards), también se puede especificar si se necesita autenticación o
no a la hora de preservar la integridad de los datos.
Apache CouchDB La polÃ​tica de CouchDB es almacenar las funciones, entre otros, en documentos
determinados. La función, por su parte, actúa sobre uno o más documentos de la base de datos. Se puede
almacenar las funciones vinculadas a un usuario o grupo y asÃ​ controlar el acceso. El poder de CouchDB en
este aspecto es que, al no tener evolución en sus versiones después de bastantes años, la comunidad
que lo utiliza es amplia y a menudo generan nuevas clases que son hechas open source mediante plug-ins
que pueden ser de utilidad. Sin embargo, una desventaja de CouchDB es que algunas cosas, como el
crecimiento de las bases de datos, no permite gestionarlas.