Mecanismos de autenticación: SCRAM y x.509

De forma predeterminada, una instancia de MongoDB recién instalada escucha en 0.0.0.0:27017 y no requiere autenticación. Innumerables filtraciones de seguridad reales se han producido porque los desarrolladores dejaron MongoDB expuesto a Internet sin habilitar la autenticación. Las implementaciones de producción deben habilitar siempre la autenticación para que solo puedan conectarse los usuarios y servicios con credenciales. MongoDB admite varios mecanismos de autenticación; los dos más importantes son SCRAM y los certificados x.509.

La autenticación se habilita añadiendo security.authorization: enabled al archivo de configuración mongod.conf (o pasando --auth en la línea de comandos). Una vez habilitada, cada intento de conexión debe proporcionar credenciales válidas. Antes de habilitar la autenticación en una implementación existente, cree siempre primero un usuario administrador; de lo contrario, se bloqueará el acceso.

Conéctese a MongoDB sin autenticación mientras se encuentre todavía en modo no autenticado (o en modo de excepción de localhost) para crear el primer usuario. Asígnele el rol userAdminAnyDatabase para que pueda crear usuarios adicionales. Después, habilite --auth y vuelva a conectarse con credenciales. La excepción de localhost permite una conexión local sin autenticación únicamente hasta que se crea el primer usuario.

SCRAM (Salted Challenge Response Authentication Mechanism) es el protocolo de autenticación mediante contraseña predeterminado de MongoDB. MongoDB utiliza de forma predeterminada SCRAM-SHA-256, la variante más nueva y segura. SCRAM evita enviar la contraseña real a través de la red: el cliente y el servidor realizan un intercambio criptográfico mediante hashes con salt. Los clientes negocian automáticamente la variante SCRAM más segura que admita el servidor.

Cada servicio de aplicación debe tener su propio usuario de MongoDB con únicamente los permisos que necesita. Un servicio de informes de solo lectura solo debe tener el rol read en la base de datos específica. Una API con un alto volumen de escrituras solo debe tener readWrite. Asignar root o dbOwner a cuentas de aplicación infringe el principio de mínimo privilegio y amplifica el impacto de una filtración.

Los certificados x.509 proporcionan una autenticación más sólida que las contraseñas mediante el uso de pares de claves criptográficas. El cliente presenta un certificado firmado por una Autoridad de certificación (CA) de confianza en lugar de un nombre de usuario y una contraseña. MongoDB asigna el Subject Distinguished Name (DN) del certificado a un usuario de MongoDB. Este es el mecanismo preferido para la autenticación interna de los miembros del clúster (los nodos del conjunto de réplicas se autentican entre sí).

Para habilitar x.509, debe configurar TLS (el transporte subyacente) y establecer security.clusterAuthMode: x509 para la autenticación entre los miembros del clúster. Para la autenticación de clientes, establezca net.tls.CAFile en el certificado de su CA para que MongoDB pueda verificar los certificados de los clientes. Esto requiere generar una CA, firmar certificados para cada miembro y cliente, y distribuirlos de forma segura.

Al utilizar la autenticación de clientes x.509, el nombre de usuario de MongoDB debe coincidir exactamente con el Subject DN del certificado del cliente. Cree el usuario en la base de datos $external (no en la base de datos normal admin ni en la de la aplicación), ya que las credenciales se validan externamente mediante el certificado y no mediante el almacén interno de credenciales de MongoDB.

SCRAM es más sencillo de configurar: cree un usuario con nombre de usuario y contraseña, y conéctese. Es adecuado para la mayoría de los servicios de aplicaciones y para el acceso de desarrolladores. x.509 es más complejo (requiere una infraestructura de PKI), pero ofrece garantías más sólidas: no hay contraseñas que rotar ni que puedan filtrarse, permite usar listas de revocación de certificados (CRL) para revocar el acceso de inmediato y es obligatorio para la autenticación de miembros de conjuntos de réplicas en entornos de alta seguridad.

MongoDB proporciona db.updateUser() para cambiar la contraseña de un usuario existente sin eliminar ni volver a crear la cuenta. En Atlas, rote las credenciales mediante la interfaz de Atlas o la API. Al rotar las credenciales, actualice la cadena de conexión de su aplicación antes de cambiar la contraseña para evitar un periodo de interrupción de la conectividad. Use variables de entorno de URI de cadena de conexión para que la rotación de contraseñas solo requiera actualizar una variable de entorno y reiniciar la aplicación.

Audite periódicamente los usuarios de MongoDB. Use db.getUsers() para enumerar todos los usuarios de una base de datos y db.getUser('name') para consultar los detalles de una cuenta específica, incluidos los roles asignados. Elimine de inmediato las cuentas obsoletas o comprometidas con db.dropUser(). En Atlas, la sección Users del panel Database Access proporciona un inventario centralizado de todos los usuarios de todos los clústeres.

En esta lección ha aprendido que SCRAM-SHA-256 es el mecanismo de autenticación predeterminado de MongoDB basado en contraseñas y es adecuado para la mayoría de los casos de uso de aplicaciones; que los certificados x.509 proporcionan una autenticación criptográfica más sólida y son preferibles para la autenticación interna de los miembros del clúster; y que debe crear siempre usuarios con roles de privilegios mínimos: las cuentas de aplicaciones nunca deben tener permisos de nivel administrativo. A continuación, profundizaremos en el control de acceso basado en roles.