Niveles de inseguridad de MongoDB y cómo evitarlos

La mayoría de los sistemas de administración de bases de datos tienen varias técnicas para proteger sus datos de un tercero o de una persona o aplicación no autorizada. Las técnicas evitan que sus datos sean leídos o copiados sin el permiso del usuario.

MongoDB no es diferente ya que tiene algunos niveles de inseguridad. En esta publicación de blog, analizaremos los niveles de inseguridad en MongoDB y cómo evitarlos para que pueda proteger su instalación de MongoDB.

Para la seguridad de su MongoDB, las siguientes son algunas de las principales medidas de seguridad que debe considerar estrictamente:
 

1. Autenticación de conexiones de usuario.

2. Autorización/ Control de acceso basado en roles.

3. Cifrado de red/ Cifrado de transporte.

4. Cifrado de almacenamiento/ Cifrado en reposo.

5. Auditoría.

En este artículo, analizaremos en detalle las medidas de seguridad anteriores, con especial énfasis en la autenticación y la autorización.

Autenticación y Autorización

La autenticación y la autorización deben activarse al unísono. Sin embargo, se pueden utilizar independientemente uno del otro. La autenticación evita que una persona desconocida que tenga acceso de red al servidor de la base de datos pueda copiar o dañar los datos de la base de datos. La autenticación requiere que todos los clientes y servidores proporcionen credenciales válidas antes de poder conectarse al sistema. La autorización, por otro lado, evita que una aplicación o un usuario lea, modifique o elimine datos que no sean los que se suponía que debían hacer.

Para configurar el control de acceso basado en roles;

1. Cree primero un administrador de usuarios.

2. Crear usuarios adicionales.

3. Luego cree un usuario único de MongoDB para cada persona/aplicación que acceda al sistema.

4. Al seguir el principio de privilegio mínimo, debe crear roles que definan los derechos de acceso exactos que necesita un conjunto de usuarios.

5. Luego, asigne a los usuarios solo las funciones que deben desempeñar en sus operaciones. Un usuario puede ser una aplicación cliente o una persona.

Debe tener en cuenta que un usuario puede tener privilegios en diferentes o múltiples bases de datos. En ese escenario, en lugar de crear un usuario varias veces en diferentes bases de datos, cree un solo usuario con roles que otorguen privilegios de base de datos aplicables.

La mayoría de las veces, estas dos medidas de seguridad pueden confundirse y significar lo mismo. En algunos escenarios, son similares entre sí, pero también son diferentes.

Similitudes entre autenticación y autorización

• Ambos son algo así como una sola unidad porque, cuando habilita la autenticación, la autorización se habilita automáticamente. La autorización se habilita al unísono con la autenticación, por lo que las conexiones de usuarios desconocidos no tendrán privilegios para acceder a los datos de la base de datos. La autorización también requiere que la autenticación verifique el nombre de usuario para saber qué privilegios se aplican a las solicitudes de una conexión. Por lo tanto, tampoco se puede habilitar de forma independiente a la otra.

• También son similares en el desafortunado nombre heredado de las opciones de configuración. La opción del archivo de configuración para la autenticación es security.authorization en lugar de la autenticación de seguridad como se esperaría. Sin embargo, cuando usa el comando, la autenticación es lo primero que se habilita y la autorización solo se habilita como un efecto posterior. “-auth” es el argumento de la línea de comando para habilitar la autenticación, lo que obliga automáticamente a que la autorización también esté activada.

Diferencias entre autenticación y autorización

• Estos dos son diferentes porque son dos partes del software que tienen funciones diferentes.

Autenticación ==Identidad del usuario, mediante verificación de credenciales.

Autorización ==Asignación y aplicación de permisos de comandos y objetos de base de datos.

• Durante la configuración inicial, la autenticación está deshabilitada para las conexiones de host local. Sin embargo, esto es breve, ya que tiene la oportunidad de crear el primer usuario, luego se elimina el privilegio de excepción (a la regla Autenticación y autorización en conjunto).

Cómo verificar si la autenticación y la autorización están habilitadas o no

Las primeras versiones de MongoDB tenían "-auth" activado de forma predeterminada y esto es ampliamente considerado como un mal movimiento. Incluso en la versión 4.0 todavía estaba desactivado de forma predeterminada. La configuración en blanco todavía equivale a que la autorización está desactivada a pesar de tener advertencias de inicio y varias reducciones de exposición, como que localhost se convierta en el único dispositivo de red predeterminado en MongoDB v3.6.

No está utilizando la autenticación o, mejor dicho, no tiene la autenticación habilitada si los archivos de configuración de mongod no la tienen:

1. Haga que security.authorization se establezca en 'habilitado'.

2. Incluya un archivo security.key.

3. Incluya una configuración security.clusterAuthMode que fuerce la autenticación.

Para verificar dos veces si tiene la autenticación y la Autorización habilitadas o no, puede probar esta línea rápida de Mongo Shell (sin establecer argumentos de credencial de usuario):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

La respuesta que debe obtener es un error "no autorizado". Pero, por otro lado, si obtiene una lista de nombres de bases de datos, automáticamente significa que tiene una implementación de MongoDB simple.

Autenticación externa

Como sugiere el nombre, la autenticación externa consiste en permitir que los usuarios se autentiquen en un servicio externo. Como excepción, no se puede usar para el usuario interno del sistema mongodb __, pero es perfectamente adecuado usarlo para cualquier usuario humano real o cuenta de servicio de aplicación de cliente.

Simplemente, el servicio de autenticación externo será un KDC Kerberos o un servidor ActiveDirectory u OpenLDAP. Debe tener en cuenta que el uso de autenticación externa no le impide tener cuentas de usuario ordinarias de MongoDB al mismo tiempo.

Autenticación interna

Por el contrario, la autenticación interna de MongoDB no significa lo contrario de la autenticación externa. Esto se debe a que un nodo mongod que se ejecuta con la autenticación habilitada no confiará en que cualquier par TCP sea otro nodo mongod o mongos solo porque se comunica como tal. Más bien, requiere que el par se autentique mediante prueba de secreto compartido.

Hay dos tipos de mecanismos de autenticación internos en MongoDB:

1. Autenticación interna de archivo de claves.

2. Autenticación interna SCRAM o x.509.

Autenticación interna de archivo de claves

Este es el mecanismo de autenticación interno predeterminado en MongoDB. El término "Clave" indica una clave de cifrado asimétrica, pero en el sentido real es solo una contraseña sin importar cómo la haya generado. El archivo de claves se guarda en un archivo idéntico distribuido a cada nodo mongod y mongos en el clúster. En el caso de que la contraseña se use con éxito, un nodo mongod permitirá que los comandos provenientes del par autenticado se ejecuten como el superusuario "_ _ system".

Si alguien tiene una copia del archivo de claves, simplemente puede eliminar los caracteres de control y no imprimibles del archivo de claves para crear la cadena de contraseña que les permitirá conectarse como el usuario del "_ _ sistema".

Sin embargo, si eso sucede y ejecuta el siguiente comando como usuario mongod (o raíz) en uno de sus servidores MongoDB y tiene éxito, no debe preocuparse ya que no habrá una fuga accidental de privilegios de lectura. . Esto se debe a que mongod cancelará el inicio si el archivo de claves está en un modo de permisos de archivo diferente a 400 (o 600).

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Sin embargo, guardar accidentalmente el archivo de claves en su control de fuente de lectura mundial puede permitir que los usuarios que no son DBA (o los administradores del servidor con root) lean una copia del archivo de claves. Esto se considera una falla de seguridad.

Un riesgo extremo aumenta cuando el archivo de claves se distribuye con nodos mongos que pertenecen y se ejecutan como uno de los usuarios de Unix del equipo de aplicaciones en lugar de "mongod" u otro usuario de Unix propiedad del equipo DBA.

SCRAM o autenticación interna x.509

El mecanismo de autenticación interno x.509 en realidad usa claves privadas o públicas asimétricas y debe usarse junto con TLS/SSL. Este mecanismo se puede utilizar tanto para conexiones de clientes como para autenticación interna.

El mecanismo x.509 o SCRAM tiene una ventaja sobre el mecanismo Keyfile porque en el mecanismo x.509, es menos probable que una de las claves implementadas con los nodos mongod y mongos pueda ser abusada por un intruso que obtiene una copia del mismo. Sin embargo, esto depende de cuán estrictamente estén configurados los certificados x.509. Para disfrutar de la máxima seguridad de este mecanismo, debe tener un equipo de seguridad dedicado que comprenda los conceptos y las mejores prácticas de x.509. Estas mejores prácticas incluyen restringir en qué hosts funcionará y poder revocar y transferir certificados.

Cifrado de red/Cifrado de transporte

El cifrado de red evita que alguien copie los datos que se transfieren a través de un enlace de red en algún lugar entre dos servidores. El cifrado de red requiere poco o ningún pensamiento cuando se trata de decidir si usarlo, ya que es crucial. Pero si, por ejemplo, su clúster de MongoDB y todos sus clientes están dentro de una red privada virtual que usted cree que no tiene agujeros en su firewall ni riesgo de escalamiento de privilegios de otras aplicaciones, entonces no necesita el cifrado de red.

Para el cifrado de red, debe configurar MongoDB para usar TLS/SSL para todas las conexiones entrantes y salientes. Cifre la comunicación entre los componentes mongod y mongos de una implementación de MOngoDB, así como entre todas las aplicaciones y MongoDB mediante TLS/SSL.

A partir de la versión 4.0; MongoDB deshabilita la compatibilidad con el cifrado TLS 1.0 en los sistemas donde está disponible TLS 1.1+ y también utiliza las siguientes bibliotecas TLS/SSL nativas:

1. Windows - Canal seguro (Schannel).

2. Linux/BSD - OpenSSL.

3. macOS - Transporte seguro.

Limitar la exposición de la red

Debe asegurarse de que MongoDB se ejecute en un entorno de red confiable y también configurar firewalls o grupos de seguridad para controlar el tráfico entrante y saliente para sus instancias de MongoDB. Más aún, configure para permitir que solo los clientes de confianza accedan a las interfaces de red y los puertos en los que están disponibles las instancias de MongoDB. Por ejemplo, utilice la lista blanca de IP para permitir el acceso desde direcciones IP de confianza.

Ejecute MongoDB con opciones de configuración seguras

MongoDB admite la ejecución de código JavaScript para las siguientes operaciones del lado del servidor:

1. mapReduce.

2. $dónde.

3. $acumulador.

4. $función.

Use la opción --noscripting en la línea de comandos para deshabilitar las secuencias de comandos del lado del servidor si no usa las operaciones anteriores. Mantenga habilitada la validación de entrada, aunque MongoDB habilita la validación de entrada de forma predeterminada a través de la configuración net.wireObjectCheck. Esto garantiza que todos los documentos almacenados por la instancia mongod sean BSON válidos.

Cifrado de almacenamiento MongoDB/ Cifrado en reposo

El cifrado de almacenamiento evita que alguien obtenga una copia de los archivos de la base de datos subyacente. Esto podría suceder cuando alguien irrumpe en su centro de datos y roba el disco duro de su servidor. Los datos de MongoDB incluyen archivos de datos, archivos de configuración, registros de auditoría y archivos clave.

A partir de MongoDB Enterprise 3.2, puede cifrar datos en la capa de almacenamiento con el cifrado en reposo nativo del motor de almacenamiento WiredTiger. Los datos de MongoDB deben cifrarse en cada host utilizando el sistema de archivos, el dispositivo o el cifrado físico cuando no se utiliza el cifrado en reposo de WiredTiger. Además, debe recopilar registros en un almacén de registros central, ya que estos registros contienen intentos de autenticación de base de datos, incluida la dirección IP de origen. Sin embargo, el cifrado de almacenamiento tiene un pequeño costo de rendimiento.

Auditoría

La auditoría ayuda a rastrear a un usuario de la base de datos que sabe cómo ocultar sus huellas después de cambiar o alterar los datos de la base de datos. Básicamente, la auditoría rastrea el acceso y las alteraciones a las configuraciones y datos de la base de datos. MongoDB Enterprise tiene una instalación de sistema de auditoría que puede registrar eventos del sistema, como operaciones de usuario y eventos de conexión en una instancia de MongoDB.

Estos registros de auditoría ayudan en el análisis forense y permiten a los administradores verificar los controles adecuados. La auditoría es de gran valor para algunos usuarios, pero solo puede serlo cuando se eliminan otros riesgos. Por ejemplo, un atacante no puede obtener acceso raíz de Unix en los servidores mientras ejecuta los nodos mongod en vivo.

Avanzando

Puede configurar filtros para registrar eventos específicos como eventos de autenticación. Pero tenga cuidado porque cuando los filtros de auditoría se hacen demasiado amplios, su rendimiento se ahogará rápidamente, lo que generará altos costos de rendimiento. Aunque, si la auditoría se usa de manera adecuada, no habrá muchos costos de rendimiento.