Seguridad preventiva con registro de auditoría para MongoDB

La seguridad de la base de datos es un tema amplio que abarca desde mediciones preventivas hasta mantener alejados a los visitantes no deseados. Incluso si pudiera asegurar sus servidores MongoDB por completo, aún le gustaría saber si alguien ha intentado ingresar a su sistema. Y si logran violar su seguridad e instalar el truco de rescate de MongoDB, necesitaría una pista de auditoría para autopsias o para tomar nuevas medidas preventivas. Un registro de auditoría le permitiría realizar un seguimiento de cualquier persona que intente iniciar sesión y ver lo que hicieron en su sistema.

La versión de MongoDB Enterprise contiene la capacidad de habilitar el registro de auditoría, pero la versión de la comunidad carece de esta funcionalidad. Percona creó su propia funcionalidad de registro de auditoría en su Percona Server para MongoDB derivado de MongoDB. Los enfoques de MongoDB y Percona son diferentes entre sí y explicaremos cómo configurar y usar ambos.

Registro de auditoría de MongoDB

El registro de auditoría de MongoDB es fácil de configurar:para habilitar el registro de auditoría en un archivo JSON, simplemente agregue la siguiente sección a su archivo de configuración y reinicie MongoDB:

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

MongoDB admite archivos, consola y syslog como destinos. Para los formatos de archivo hay dos opciones:JSON y BSON. En JSON, las líneas de registro de auditoría se parecen a esto:

{ "atype" : "authCheck", "ts" : { "$date" : "2017-02-15T22:20:08.322-0000" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 63357 }, "users" : [], "roles" : [], "param" : { "command" : "update", "ns" : "test.inserttest", "args" : { "update" : "preauth_case", "updates" : [ { "q" : { "createdByUserId" : -2 }, "u" : { "$set" : { "statusCode" : "Update" } }, "multi" : false, "upsert" : false } ], "ordered" : true } }, "result" : 0 }

La configuración anterior habilitaría el registro de auditoría para todas y cada una de las acciones de cualquier usuario de su sistema. Si tiene una alta concurrencia, esto disminuiría drásticamente el rendimiento de su clúster MongoDB. Afortunadamente, existe la opción de filtrar los eventos que deben registrarse.

Los filtros para el registro de auditoría se pueden colocar en el tipo de consulta, el usuario/rol que consulta o en la colección que se está consultando. La documentación sobre el registro de auditoría en MongoDB es muy amplia y extensa, con muchos ejemplos. Daremos algunos de los ejemplos más importantes a continuación.

Autenticación contra una colección específica:

    filter: '{ atype: "authenticate", "param.db": "test" }'

Registro para varios tipos de auditoría:

    filter: '{ atype: { $in [ "update", "delete" ]}, "param.db": "test" }'

Registre todas las comprobaciones de autenticación para insertar/actualizar/eliminar en una colección específica:

    filter: '{ atype: "authCheck", "param.ns": "test.orders", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'

Como puede ver, los filtros pueden ser bastante flexibles y podrá filtrar los mensajes que necesita para su registro de auditoría.

Servidor Percona para el registro de auditoría de MongoDB

El registro de auditoría de Percona Server para MongoDB está limitado al archivo JSON. La mayoría de los usuarios solo iniciarán sesión en archivos JSON, pero no está claro si Percona agregará otras funciones de registro en el futuro.

Según la versión de Percona Server para MongoDB, su configuración puede ser diferente. Al momento de escribir, todas las versiones tienen la siguiente sintaxis:

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

Sin embargo, esta diferencia de configuración se ha resuelto recientemente, pero aún debe publicarse. Después del lanzamiento, debe seguir la directiva auditLog de MongoDB nuevamente:

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

El formato de Percona es ligeramente diferente:

{ "atype" : "authenticate", "ts" : { "$date" : { "$numberLong" : "1487206721903" } }, "local" : { "host" : "n3", "port" : 27017 }, "remote" : { "host" : "172.16.140.10", "port" : 50008 }, "users" : [ { "user" : "admin", "db" : "admin" } ], "params" : { "user" : "admin", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 0 }

A diferencia de MongoDB que registra todo, Percona eligió registrar solo los comandos importantes. A juzgar por la fuente del complemento de auditoría de Percona, se admiten las siguientes consultas:autenticación, crear/actualizar/eliminar usuarios, agregar/actualizar/eliminar roles, crear/eliminar base de datos/índice y la mayoría de los comandos de administración importantes.

Además, el filtrado del registro de auditoría de Percona Server para MongoDB no parece seguir el mismo estándar que tiene MongoDB. No está muy claro cuál es la sintaxis y las opciones exactas del filtro, ya que la documentación de Percona es muy concisa al respecto.

Habilitar el registro de auditoría sin filtrar le daría más que suficientes entradas en su archivo de registro. Desde aquí puede restringir el filtro, ya que sigue la sintaxis JSON de las entradas de registro.

Hacer uso del registro de auditoría

Para que sea más fácil para usted, podría ser mejor introducir el registro de auditoría en un marco de análisis de registros. Una pila ELK es un entorno excelente para realizar su análisis y le permite profundizar en niveles más detallados con bastante facilidad. El uso de un mapeador de campo incluso le permitiría hacer la pista de auditoría dentro de ELK.

Como se describe en la introducción, podemos usar el registro de auditoría para varios propósitos de seguridad. El más obvio es cuando lo necesita como referencia durante una autopsia. 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 un poco menos de información, pero debería ser suficiente para la mayoría de las autopsias. Usar el registro de auditoría para autopsias es excelente, aunque preferiríamos haber evitado el problema en primer lugar.

Otro propósito para el registro de auditoría es ver las tendencias que suceden y podría establecer trampas en un determinado mensaje de registro de auditoría. Un buen ejemplo sería verificar la tasa de intentos de autenticación (fallidos) y, si supera cierto umbral, actuar en consecuencia. Dependiendo de la situación, la acción tomada podría diferir. Una acción podría ser bloquear automáticamente la dirección IP de la que provienen las solicitudes, pero en otro caso, podría consultar con el usuario sobre por qué se olvidó la contraseña. Realmente depende del caso y el entorno en el que esté trabajando.

Otra medida preventiva avanzada sería usar MongoDB como trampa y aprovechar el registro de auditoría para atrapar usuarios no deseados. Simplemente exponga MongoDB y permita que cualquiera se conecte a su servidor MongoDB. Luego use el registro de auditoría para detectar qué harán los usuarios si se les permite hacer cosas más allá de sus poderes normales y bloquearlos si es necesario. La mayoría de los humanos prefieren tomar el camino más fácil que el más difícil, por lo que el honeypot podría desviar un ataque y el hacker pasaría al siguiente objetivo.

Conclusión

Además de explicar cómo configurar el registro de auditoría para MongoDB Enterprise y Percona Server para MongoDB, también explicamos lo que podría hacer con los datos registrados dentro del registro de auditoría.

De manera predeterminada, ClusterControl no habilitará el registro de auditoría, pero es relativamente fácil habilitarlo en todo el clúster mediante nuestro Administrador de configuración. También puede habilitarlo dentro de las plantillas de configuración, antes de implementar un nuevo clúster.

¡Feliz agrupamiento!