Puede exigir que los nodos de sets de réplicas y clústeres se autentican entre sí. Para la autenticación interna de los nodos, MongoDB puede usar archivos clave o x.509 certificados.
El método seleccionado se utiliza para toda la comunicación interna. Por ejemplo, cuando un cliente se autentica en un mongos usando uno de los mecanismos de autenticación compatibles, mongos utiliza entonces el método interno de autenticación configurado para conectarse a los mongod procesos requeridos.
Nota
Habilitar la autenticación interna también habilita la autorización de clientes.
Archivos clave
Los archivos clave utilizan el mecanismo de autenticación de desafío y respuesta SCRAM, donde los archivos clave contienen la contraseña compartida para los nodos.
Requisitos clave
La longitud de una clave debe estar entre 6 y 1024 caracteres y solo puede contener caracteres del conjunto base64. MongoDB elimina los caracteres de espacio en blanco (por ejemplo, x0d, x09 y x20) para una cómoda integración multiplataforma. Como resultado, las siguientes operaciones producen claves idénticas:
echo -e "mysecretkey" > key1 echo -e "my secret key" > key1 echo -e "my secret key\n" > key2 echo -e "my secret key" > key3 echo -e "my\r\nsecret\r\nkey\r\n" > key4
Formato del fichero de claves
Los archivos clave para la autenticación interna de miembros utilizan el formato YAML para permitir múltiples claves en un archivo clave. El formato YAML acepta cualquiera de los siguientes:
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.
Por ejemplo,
Si el archivo clave contiene una sola clave, puedes especificar la string clave con o sin comillas:
my old secret key1
Puede especificar varias cadenas clave [1] como una secuencia de cadenas clave (opcionalmente entre comillas):
- my old secret key1 - my new secret key2
La capacidad de especificar varias claves en un archivo permite la actualización progresiva de las claves sin interrupciones. Consulte Rotar llaves para conjuntos de réplicas autogestionados y Rotar llaves para clústeres fragmentados autogestionados.
Todas las mongod y mongos instancias de una implementación deben compartir al menos una clave común.
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.
Debes almacenar el archivo de claves en cada servidor donde esté alojado el nodo del conjunto de réplicas o del clúster fragmentado.
| [1] | Para el motor de almacenamiento cifrado de MongoDB, el archivo de claves utilizado para la gestión local de claves solo puede contener una única clave . |
Configuración de MongoDB para Keyfile
Para especificar el archivo clave, utiliza la configuración security.keyFile o la opción de línea de comandos --keyFile.
Para un ejemplo de autenticación interna mediante keyfile, consulta Actualizar el set de réplicas autogestionado a autenticación por keyfile.
X.509
Los nodos de un set de réplicas o un clúster fragmentado pueden usar certificados x.509 para autenticación interna en lugar de usar archivos clave. Esto también se conoce como autenticación mútua Trust o mTLS. MongoDB admite la autenticación de certificados x.509 para su uso con una conexión TLS/SSL segura.
Nota
MongoDB deshabilita el soporte para el cifrado TLS 1.0 en sistemas donde TLS 1.1+ está disponible.
Requisitos del certificado de nodo
Los certificados de miembro que usas para verificar la membresía en un clúster fragmentado o en un set de réplicas (net.tls.clusterFile, si se especifica, y net.tls.certificateKeyFile), deben tener las siguientes propiedades:
Una única Autoridad Certificadora (CA) debe emitir todos los certificados x.509 para los nodos de un clúster o un set de réplicas.
El Nombre Distinguido (
DN), que se encuentra en elsubjectdel certificado de nodo, debe especificar un valor no vacío para al menos uno de los siguientes atributos:la organización (
O)la Unidad Organizativa (
OU)El componente del dominio (
DC)
Los atributos de la organización (
O), los atributos de la unidad organizativa (OU) y los componentes del dominio (DC) deben coincidir con los de ambos certificadosnet.tls.clusterFileynet.tls.certificateKeyFilepara los demás miembros del clúster (o el valor detlsX509ClusterAuthDNOverride, si está configurado).Para coincidir, el certificado debe coincidir con todas las especificaciones de estos atributos, incluso la no especificación de estos atributos. El orden de los atributos no importa.
En el siguiente ejemplo, los dos
DNcontienen especificaciones coincidentes paraO,OU, así como la no especificación del atributoDC.CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2 Sin embargo, los dos siguientes
DNcontienen una diferencia en el atributoOUporque uno de ellos contiene dos especificacionesOUy el otro solo una especificación.CN=host1,OU=Dept1,OU=Sales,O=MongoDB CN=host2,OU=Dept1,O=MongoDB En implementaciones multi-cluster, cada clúster debe usar un certificado de nodo X.509 diferente. Cada certificado debe tener valores únicos en los campos del Nombre Distinguido (ND)
O,OUyDC.Si dos clústeres tienen certificados con los mismos valores de nombre distinguido, un servidor comprometido en un clúster puede autenticarse como nodo del otro.
El Nombre Común (
CN) o una de las entradas de Nombre Alternativo del Sujeto (SAN) deben coincidir con el nombre del servidor para los demás nodos del clúster. A partir de MongoDB 4.2, al compararSANs, MongoDB puede comparar nombres DNS o direcciones IP. En versiones anteriores, MongoDB solo compara nombres DNS.Por ejemplo, los certificados para un clúster podrían tener los siguientes sujetos:
subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US Si el certificado utilizado como el
certificateKeyFileincluyeextendedKeyUsage, el valor debe incluir tantoclientAuth(“Autenticación de cliente web TLS”) comoserverAuth(“Autenticación de servidor web TLS”).extendedKeyUsage = clientAuth, serverAuth Si el certificado utilizado como
clusterFileincluyeextendedKeyUsage, el valor debe incluirclientAuth.extendedKeyUsage = clientAuth El certificado x.509 no debe estar caducado.
mongod/mongosgenera un registro de advertencia en la conexión si el certificado X.509 presentado caduca dentro de30días a partir de la hora del sistema hostmongod/mongos.
Configuración de MongoDB
Se puede usar TLS para la autenticación interna entre cada miembro del set de réplicas (cada instancia mongod) o de un clúster particionado (cada instancia mongod y mongos).
Para utilizar TLS para la autenticación interna, utiliza la siguiente configuración:
security.clusterAuthModeo--clusterAuthModeconfigurado parax509
Las instancias mongod y mongos utilizan su archivo clave de certificado para demostrar su identidad a los clientes, pero también se puede usar para la autenticación de membresía. Si no se especifica un archivo de clúster, los nodos utilizarán sus archivos de claves de certificados para la autenticación de membresía. Especifica el archivo de clave del certificado con net.tls.certificateKeyFile o --tlsCertificateKeyFile.
Para utilizar el certificate key file tanto para la autenticación del cliente como la autenticación de membresía, el certificado debe:
Omite
extendedKeyUsageoEspecifica
extendedKeyUsage = serverAuth, clientAuth
Próximos pasos
Para ver un ejemplo de autenticación interna x.509, consulta Usar un certificado x.509 para la autenticación de membresía con MongoDB autogestionado.
Para actualizar desde la autenticación interna con archivo de claves hasta la autenticación interna de x.509, consulte Actualizar MongoDB Autogestionado desde Autenticación con Archivo de Claves a Autenticación de x.509.