Control de acceso basado en roles (RBAC) en MongoDB

A medida que más personas se conectan en esta era digital, aumenta la necesidad de definir permisos y roles para garantizar la seguridad y gestionar el acceso a aplicaciones y sistemas. El control de acceso basado en roles es un modelo de autorización que regula el acceso a los recursos según los roles predefinidos de los usuarios. 

Con el modelo RBAC de MongoDB, las acciones se representan como roles que se asignan a los usuarios adecuados. Por ejemplo, en lugar de asignar varios permisos individuales, puedes asignar un único rol (p. ej., dbAdmin) que ya incluye el conjunto de permisos definidos (p. ej., lectura sobre las colecciones de la base de datos). Este modelo facilita la gestión del acceso de forma escalable.

Cómo habilitar RBAC en MongoDB

Con el modelo básico de RBAC, el acceso está denegado por defecto, lo que significa que los usuarios no pueden acceder a los recursos si no tienen asignado algún rol. Un usuario puede tener varios roles, y cada rol incluye un conjunto específico de privilegios o permisos para acceder a determinadas capacidades.

Conceptos básicos de RBAC

Aquí tienes algunos conceptos clave que debes conocer sobre RBAC:

Usuarios

En el modelo RBAC, un usuario es una entidad a la que se le conceden uno o varios roles que determinan su acceso a los recursos y operaciones de la base de datos. Un usuario no tendrá acceso al sistema si no tiene roles asignados. Para acceder, debe autenticarse y tener al menos un rol asignado.

Roles

MongoDB incluye roles y privilegios predeterminados tanto para despliegues autogestionados como para MongoDB Atlas. Algunos roles integrados habituales son read, readWrite y dbAdmin/atlasAdmin. Los roles de administración de base de datos tienen privilegios más elevados que el resto, incluido el de gestionar los privilegios de otros roles.

Si estos roles predeterminados no cubren los privilegios que necesitas, MongoDB ofrece métodos para crear y modificar roles definidos por el usuario.

Un rol es un conjunto de privilegios que se asigna al usuario.

Por ejemplo, un rol "read" puede incluir privilegios de solo lectura, un rol "admin" puede incluir lectura y escritura, mientras que el rol "owner" puede tener lectura, escritura y borrado sobre un elemento concreto (una base de datos, un documento, etc.). Un rol concede privilegios para realizar acciones específicas sobre recursos. Cada privilegio puede estar definido explícitamente en el rol o heredarse de otro rol, o ambas cosas.

Roles definidos por el usuario / roles personalizados

MongoDB proporciona varios roles integrados que los administradores pueden usar para controlar el acceso a un sistema MongoDB. Sin embargo, si los roles existentes no describen los privilegios específicos que buscas, puedes definir y asignar nuevos roles a los usuarios de una base de datos: eso es un rol personalizado. Con la excepción de los roles creados en la base de datos admin, un rol solo puede incluir privilegios que apliquen a su propia base de datos y solo puede heredar de otros roles de esa misma base de datos.

Para crear un rol nuevo, utiliza el método db.createRole(), especificando los privilegios en el array privileges y los roles heredados en el array roles.

MongoDB utiliza la combinación del nombre de la base de datos y el nombre del rol para identificarlo de forma única, y almacena toda la información de roles en la colección admin.system.roles de la base de datos admin.

Ejemplo: este ejemplo crea un rol personalizado (sales_attendant) que solo puede insertar documentos en la colección sales de la base de datos sales_db.

use sales
db.createRole(
   {
     role: "sales_attendant",
     privileges: [
       {
         resource: { db: "sales_db", collection: "sales" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)

Roles integrados 

Los roles integrados son roles precreados que se asignan a los usuarios y les permiten realizar operaciones como leer y escribir en colecciones de una base de datos. Ejemplos de roles integrados: read, write, readWrite, dbAdmin y readAnyDatabase.

• read y readWrite (acceso a nivel de base de datos): estos roles conceden acceso para realizar operaciones de solo lectura o de lectura/escritura, respectivamente, sobre todas las colecciones no de sistema dentro de una base de datos concreta.
• dbAdmin: este rol concede derechos administrativos necesarios para gestionar una base de datos específica, como crear, eliminar y modificar índices y colecciones. Es idóneo para equipos de desarrollo o scripts de mantenimiento de bases de datos.
• clusterAdmin (acceso operativo): rol de alto privilegio, normalmente reservado para personal de operaciones (DevOps/Ops). Concede permisos necesarios para gestionar todo el despliegue de MongoDB, incluidos la creación de copias de seguridad periódicas, la configuración de réplicas y el sharding.

Privilegios (permisos)

Los privilegios son un conjunto de acciones (p. ej., find, insert) permitidas sobre una capacidad.

Por ejemplo, si la capacidad es "informar al cliente de su saldo actual", entonces los privilegios del usuario (pongamos, la persona de caja) podrían ser de solo lectura. Si la capacidad es aumentar el límite de transacciones de una cuenta bancaria, los privilegios podrían ser de lectura y escritura.

Privilegios heredados

Un rol puede incluir uno o más roles existentes (con todos sus privilegios). Por ejemplo, un rol dbAdmin puede incluir roles de lectura, escritura y actualización (que pueden ser roles individuales) con los privilegios asociados.

Recursos

Un recurso puede ser una base de datos, una colección, un conjunto de colecciones o el clúster. 

Aplicar el principio de mínimo privilegio

En la seguridad de bases de datos moderna, el principio de mínimo privilegio (PoLP) es fundamental. Este principio establece que a cada usuario se le deben asignar solo los permisos mínimos necesarios para realizar sus tareas.

Un ejemplo de buena práctica: en lugar de usar un usuario global con readWrite, crea usuarios específicos por aplicación. Por ejemplo, si tu servicio de inventario solo interactúa con la base de datos app_data, el usuario de la aplicación debe tener acceso readWrite únicamente a esa base de datos. Esta compartimentación evita que, si un servicio se ve comprometido, obtenga acceso no autorizado a otras bases de datos (como billing o users).

Ejemplo de código: 

Creación de un usuario con mínimo privilegio. Este ejemplo crea un usuario (branch_manager) con acceso de lectura/escritura limitado estrictamente a la base de datos bank_data.

use admin
db.createUser(
   {
     user: "branch_manager",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "bank_data" }
     ]
   }
)

Buenas prácticas

• Define y asigna roles y políticas claras con antelación.
• Sigue el principio de mínimo privilegio para reforzar la seguridad.
• Utiliza los roles integrados siempre que sea posible y audita periódicamente los roles asignados para detectar anomalías.