Overview
Implementar el control de acceso en un Elconjunto de réplicas requiere configuración:
La seguridad entre los miembros del Set de réplicas mediante Autenticación Interna, y
Seguridad entre los clientes conectados y el Set de réplicas utilizando Control de acceso basado en roles en implementaciones autogestionadas.
Para este tutorial, cada nodo del set de réplicas utiliza el mismo mecanismo de autenticación interna y la misma configuración.
La aplicación de la autenticación interna también refuerza el control de acceso de los usuarios. Para conectarse al conjunto de réplicas, los clientes como mongoshnecesita usar una cuenta de usuario. Consulte Usuarios y mecanismos de autenticación.
Cloud Manager y Ops Manager
Si actualmente se está utilizando o planea utilizar Cloud Manager o Ops Manager, consultar el manual de Cloud Manager o el manual de Ops Manager para aplicar el control de acceso.
Considerations
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
Asociación de IP
mongod y mongos se enlazan a localhost por defecto. Si los miembros de la implementación se ejecutan en hosts diferentes o si se desea que clientes remotos se conecten a la implementación, se debe especificar --bind_ip o net.bindIp.
Sistema operativo
Este tutorial se refiere principalmente al proceso de mongod. Los usuarios de Windows deberían usar el programa mongod.exe en su lugar.
Seguridad del archivo de claves
Recomendamos los archivos de claves solo para entornos de prueba y desarrollo, debido a sus limitaciones en cuanto a capacidad de gestión y fortaleza criptográfica. Para entornos de producción, aconsejamos encarecidamente el uso de certificados X.509. Aunque los archivos de claves pueden ser seguros en escenarios específicos y controlados, presentan desafíos de escalabilidad y gestión en implementaciones complejas. Los certificados X.509 ofrecen características de seguridad más robustas, permiten una mejor gestión de claves, admiten la autenticación individual y cumplen con los estándares de la industria para la protección de datos sensibles.
Usuarios y mecanismos de autenticación
Este tutorial cubre la creación del número mínimo de usuarios administrativos únicamente en la base de datos admin. Para la autenticación de usuario, el tutorial utiliza el mecanismo de autenticación SCRAM por defecto. Los mecanismos de seguridad de desafío-respuesta son más adecuados para entornos de prueba o desarrollo. Para entornos de producción, recomendamos usar certificados X.509 o Autenticación Proxy LDAP autogestionada (disponible solo para MongoDB Enterprise) o Autenticación Kerberos en implementaciones autogestionadas (disponible solo para MongoDB Enterprise).
Para obtener detalles sobre la creación de usuarios para un mecanismo de autenticación específico, consultar las páginas correspondientes a cada mecanismo de autenticación.
Consultar ➤ Configurar el Control de Acceso Basado en Roles para conocer las mejores prácticas para la creación y gestión de usuarios.
Implementar un nuevo Set de réplicas con control de acceso mediante archivo de claves
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
Crea un archivo de claves.
Con la autenticación keyfile, cada instanciasmongod del set de réplicas utiliza el contenido del keyfile como contraseña compartida para autenticar a otros miembros en la implementación. Solo mongod instancias con el archivo de clave correcto pueden unirse al set de réplicas.
Nota
Los archivos de claves para la autenticación interna de miembros utilizan el formato YAML para permitir múltiples claves en un archivo de claves. El formato YAML acepta:
Una string de clave única (igual que en versiones anteriores)
Una secuencia de cadenas clave
El formato YAML es compatible con los archivos de claves de una sola clave existentes que utilizan el formato de archivo de texto.
La longitud de una clave debe estar entre 6 y 1024 caracteres y solo puede contener caracteres del conjunto base64. Todos los miembros del set de réplicas deben compartir al menos una clave común.
Nota
En los sistemas UNIX, el archivo de claves no debe tener permisos de grupo ni de otros. En los sistemas Windows, no se verifican los permisos de los archivos de claves.
Se puede generar un archivo de claves utilizando cualquier método que se elija. Por ejemplo, la siguiente operación utiliza openssl para generar un string de caracteres complejo pseudoaleatorio de 1024 caracteres que se utilizará como contraseña compartida. Luego utiliza chmod para cambiar los permisos del archivo para proporcionar permisos de lectura solo al propietario del archivo:
openssl rand -base64 756 > <path-to-keyfile> chmod 400 <path-to-keyfile>
Consultar Keyfiles para obtener más información y requisitos para el uso de los keyfiles.
Copiar el archivo de claves a cada miembro del Set de réplicas.
Copia el archivo de claves en cada servidor que aloje a los miembros del Set de réplicas. Asegúrate de que el usuario que ejecuta las instancias de mongod sea el propietario del archivo y pueda acceder al archivo de claves.
Evitar almacenar el archivo de claves en medios de almacenamiento que puedan desconectarse fácilmente del hardware que aloja las instancias de mongod, como una unidad USB o un dispositivo de almacenamiento conectado a la red.
Inicia cada nodo del Set de réplicas con el control de acceso habilitado.
Para cada nodo del Set de réplicas, inicia el mongod con la configuración del archivo de configuraciónsecurity.keyFile o la opción de línea de comandos --keyFile. Ejecutar mongod con la opción de línea de comandos --keyFile o la configuración del archivo security.keyFile de configuración aplica tanto la Autenticación Interna/de Membresía Autogestionada como, además, el Control de acceso basado en roles en implementaciones autogestionadas.
archivo de configuración
Si utiliza un archivo de configuración, establezca
security.keyFilea la ruta del archivo de claves, yreplication.replSetNameal nombre del Set de réplicas.
Incluye opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a la implementación o si los miembros de la implementación se ejecutan en diferentes hosts, se debe especificar la configuración net.bindIp.
security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName> net: bindIp: localhost,<hostname(s)|ip address(es)>
Inicia la mongod usando el archivo de configuración:
mongod --config <path-to-config-file>
Para obtener más información sobre el archivo de configuración, consultar opciones del archivo de configuración.
Línea de comandos
Si utiliza las opciones de línea de comandos, inicie el mongod con las siguientes opciones:
--keyFileconfigurado en la ruta del archivo de clave, y--replSetconfigura el nombre del Set de réplicas.
Incluir opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a su implementación o si los miembros de su implementación se ejecutan en hosts diferentes, especificar el --bind_ip.
mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
Para obtener más información sobre las opciones de la línea de comandos, consulte la mongod página de referencia.
Conectarse a un nodo del set de réplicas a través de la interfaz localhost.
Conecta mongosh a una de las instancias de mongod a través de la interfaz localhost. Debes ejecutar mongosh en la misma máquina física que la instancia mongod.
La interfaz de localhost solo está disponible porque no se han creado usuarios para la implementación. La interfaz localhost se cierra después de la creación del primer usuario.
Inicia el set de réplicas.
Desde mongosh, ejecuta el método rs.initiate().
rs.initiate() puede tomar un documento de configuración de Set de réplicas opcional. En el documento de configuración del Set de réplicas, incluya:
El campo
_idse establece en el nombre del Set de réplicas especificado en elreplication.replSetNameo en la opción--replSet.El
membersarreglo con un documento por cada nodo del set de réplicas.
El siguiente ejemplo inicia un Set de réplicas de tres nodos.
Importante
Se debe ejecutar rs.initiate() en una sola instancia mongod para el set de réplicas.
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
rs.initiate( { _id : "myReplSet", members: [ { _id : 0, host : "mongo1.example.net:27017" }, { _id : 1, host : "mongo2.example.net:27017" }, { _id : 2, host : "mongo3.example.net:27017" } ] } )
rs.initiate() activa una elección y elige a uno de los miembros para que sea el primario.
Conéctate al primario antes de continuar. Utiliza rs.status() para localizar al miembro primario.
Crear el usuario administrador
Importante
Después de que se cree el primer usuario, la excepción localhost ya no está disponible.
El primer usuario debe tener privilegios para crear otros usuarios, como un usuario con el userAdminAnyDatabase. Esto asegura que puedas crear usuarios adicionales después de que se cierre la Excepción de Localhost en Implementaciones Autogestionadas.
Si al menos un usuario no tiene privilegios para crear usuarios, una vez que se cierre la excepción de localhost, es posible que no se pueda crear o modificar usuarios con nuevos privilegios y, por lo tanto, no se pueda acceder a las operaciones necesarias.
Añadir un usuario usando el método db.createUser(). El usuario debe tener como mínimo el rol userAdminAnyDatabase en la base de datos admin.
Debe estar conectado al primario para crear usuarios.
El siguiente ejemplo crea al usuario fred con el rol userAdminAnyDatabase en la base de datos admin.
Importante
Las contraseñas deben ser aleatorias, largas y complejas para garantizar la seguridad del sistema y para prevenir o retrasar el acceso malicioso.
Tip
Puedes usar el método passwordPrompt() en conjunto con varios métodos y comandos de gestión de autenticación de usuarios para solicitar la contraseña en lugar de especificar la contraseña directamente en la llamada al método o comando. Sin embargo, aún puedes especificar la contraseña directamente como lo harías con las versiones anteriores del shell mongo.
admin = db.getSiblingDB("admin") admin.createUser( { user: "fred", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )
Se debe ingresar la contraseña cuando se indique. Se debe consultar Roles de usuario de base de datos para ver una lista completa de los roles incorporados relacionados con las operaciones de administración de bases de datos.
Autentícate como el administrador de usuario.
Autentícate en la base de datos admin.
En mongosh, utiliza db.auth() para autenticarte. Por ejemplo, los siguientes se autentican como el usuario administrador fred:
Tip
Puedes usar el método passwordPrompt() en conjunto con varios métodos y comandos de gestión de autenticación de usuarios para solicitar la contraseña en lugar de especificar la contraseña directamente en la llamada al método o comando. Sin embargo, aún puedes especificar la contraseña directamente como lo harías con las versiones anteriores del shell mongo.
db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password
Como alternativa, conecta||||||| una nueva mongosh instancia al miembro primario del Set de réplicas utilizando los parámetros -u <username>, -p <password> y --authenticationDatabase.
mongosh -u "fred" -p --authenticationDatabase "admin"
Si no especificas la contraseña para la opción de línea de comandos -p, mongosh solicita la contraseña.
Crea el administrador del clúster.
El clusterAdmin rol otorga acceso a las operaciones de replicación, como la configuración del Set de réplicas.
Cree un usuario administrador del clúster y asígnele el rol de clusterAdmin en la base de datos admin:
Tip
Puedes usar el método passwordPrompt() en conjunto con varios métodos y comandos de gestión de autenticación de usuarios para solicitar la contraseña en lugar de especificar la contraseña directamente en la llamada al método o comando. Sin embargo, aún puedes especificar la contraseña directamente como lo harías con las versiones anteriores del shell mongo.
db.getSiblingDB("admin").createUser( { "user" : "ravi", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )
Introduzca la contraseña cuando se lo pidan.
Consultar Roles de administración de clústeres para obtener una lista completa de los roles incorporados relacionados con las operaciones de sets de réplicas y clústeres.
Crear usuarios adicionales (Opcional).
Crear usuarios para permitir que los clientes se conecten e interactúen con el set de réplicas. Consultar Roles de usuario de base de datos para roles básicos incorporados que se pueden utilizar en la creación de usuarios de solo lectura y lectura-escritura.
También puede que desees usuarios administrativos adicionales. Para obtener más información sobre los usuarios, consulta Usuarios en implementaciones autogestionadas.
X.509 Autenticación Interna
Para obtener detalles sobre el uso de X.509 para la autenticación interna, consultar Verificar la pertenencia al clúster con X.509 en MongoDB autogestionado.
Para actualizar de la autenticación interna del archivo de claves a la autenticación interna X.509, consultar Actualización de la autenticación del archivo de claves a la autenticación X.509.