MongoDB admite la autenticación de certificado x.509 para la autenticación del cliente y la autenticación interna de los miembros de conjuntos de réplicas y clústeres fragmentados.
La autenticación del certificado x.509 requiere un certificado seguro Conexión TLS/SSL.
Autoridad de Certificación
Para uso en producción, la implementación de MongoDB debe utilizar certificados válidos generados y firmados por una autoridad certificadora. El usuario o la organización pueden generar y mantener una autoridad de certificación independiente, o utilizar certificados generados por proveedores de TLS de terceros. La obtención y gestión de certificados está fuera del alcance de esta documentación.
Certificados del cliente x.509
Para autenticarse en los servidores, los clientes pueden usar certificados x.509 en lugar de nombres de usuario y contraseñas.
Requisitos del certificado de cliente
Los certificados de cliente deben tener las siguientes propiedades:
Una única entidad de certificación (CA) debe emitir los certificados tanto para el cliente como para el servidor.
Los certificados de cliente deben contener los siguientes campos:
keyUsage = digitalSignature extendedKeyUsage = clientAuth Cada usuario único de MongoDB debe tener un certificado único.
Un asunto del certificado de cliente x.509, que contiene el nombre distinguido (
DN), deben ser diferentes de los sujetos de los certificados del miembro x..509Importante
509 Si
OOUDCel asunto de un certificado de cliente x. coincide exactamente con los atributos, y del509 Certificado de miembro x.tlsX509ClusterAuthDNOverride(o, si está configurado), se acepta la conexión del cliente, se otorgan permisos completos y aparece un mensaje de advertencia en el registro.Solo los certificados x509 de nodos del clúster deben utilizar las mismas combinaciones de atributos
O,OUyDC.Si la implementación de MongoDB tiene configurado,
tlsX509ClusterAuthDNOverrideel509 asunto del certificado del cliente x. no debe coincidir con ese valor.Si la implementación de MongoDB tiene configurado, el asunto del certificado del cliente
tlsX509ClusterAuthDNOverridex.509 también debe ser diferente de ese valor.El certificado509 x. no debe estar vencido.
mongod/ registra una advertencia en la conexión simongosel509 certificado x. presentado caduca dentro de los30días posteriores a la hora delmongod/mongossistema host.
Usuario de MongoDB y base de datos $external
Para autenticarse con un certificado de cliente, primero debe agregar el valor subject del certificado de cliente como usuario de MongoDB. Cada certificado de cliente x.509 único corresponde a un único usuario de MongoDB. No se puede usar un solo certificado de cliente para autenticar a más de un usuario de MongoDB.
Agregue el usuario a la $external base de datos. La $external base de datos es la base de datos de autenticación del usuario.
Para utilizar sesiones de cliente y garantías de consistencia causal con $external usuarios de autenticación (Kerberos, LDAP o x.509 usuarios), los nombres de usuario no pueden tener más de 10k bytes.
Advertencia de inicio de conexión TLS con certificado X509
A partir de MongoDB 5.0, mongod y mongos ahora emiten una advertencia de inicio cuando sus certificados no incluyen un atributo Nombre Alternativo del Sujeto.
Las siguientes plataformas no admiten la validación de nombres comunes:
iOS 13 y superior
MacOS 10.15 y superior
Go 1.15 o superior
Los clientes que utilizan estas plataformas no se autenticarán en los servidores MongoDB que utilizan el certificado509 X. cuyos nombres de host están especificados por los atributos CommonName.
Certificados de nodo x.509
Para la autenticación interna entre miembros de clústeres fragmentados y conjuntos de réplicas, se pueden utilizar certificados x.509 en lugar de archivos clave, utilizando el mecanismo de autenticación SCRAM.
Requisitos del certificado de nodo
Los certificados de miembro que utiliza para verificar la membresía a un clúster fragmentado o un conjunto de réplicas (, sinet.tls.clusterFile net.tls.certificateKeyFile se especifica, y), deben tener las siguientes propiedades:
Una única autoridad de certificación (CA) debe emitir todos los certificados x.509 para los miembros de un clúster fragmentado o un conjunto de réplicas.
El nombre distinguido
DN(), que se encuentra en el del certificado desubjectmiembro, 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 (), los atributos de la unidad organizativa
OOU() y los componentes del dominioDC() deben coincidir con los de losnet.tls.clusterFilecertificados y de los otrosnet.tls.certificateKeyFiletlsX509ClusterAuthDNOverridemiembros del clúster (o el valor, si está configurado).Para que coincida, el certificado debe cumplir todas las especificaciones de estos atributos, incluso si no se especifican. El orden de los atributos es irrelevante.
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
DNsiguientes contienen una falta de coincidencia para el atributoOUya que uno contiene dos especificacionesOUy el otro, solo una.CN=host1,OU=Dept1,OU=Sales,O=MongoDB CN=host2,OU=Dept1,O=MongoDB En implementaciones multiclúster, cada clúster debe usar un509 certificado miembro X. diferente. Cada certificado debe tener valores únicos en los campos de nombre distintivo
OOUDC(DN), y.Si dos clústeres tienen certificados con los mismos valores DN, un servidor comprometido en un clúster puede autenticarse como miembro del otro.
El nombre común (
CN) o una de las entradas del nombre alternativo del sujeto (SAN) deben coincidir con el nombre de host del servidor de los demás miembros del clúster. A partir de MongoDB 4.2, al compararSAN, MongoDB puede comparar nombres DNS o direcciones IP. En versiones anteriores, MongoDB solo comparaba nombres DNS.Por ejemplo, los certificados de un clúster podrían tener los siguientes temas:
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
certificateKeyFileincluyeextendedKeyUsage, el valor debe incluirclientAuth("Autenticación de cliente web TLS") yserverAuth("Autenticación de servidor web TLS").extendedKeyUsage = clientAuth, serverAuth Si el certificado utilizado como
clusterFileincluyeextendedKeyUsage, el valor debe incluirclientAuth.extendedKeyUsage = clientAuth El certificado509 x. no debe estar vencido.
mongod/ registra una advertencia en la conexión simongosel509 certificado x. presentado caduca dentro de los30días posteriores a la hora delmongod/mongossistema host.
Configuración de MongoDB para la autenticación de nodos
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
mongod Las mongos instancias y usan su archivo de clave de certificado para demostrar su identidad a los clientes, pero también pueden usarse para la autenticación de miembros. Si no especifica un archivo de clúster, los miembros usan sus archivos de clave de certificado para la autenticación de miembros. Especifique el archivo de clave de certificado con net.tls.certificateKeyFile o.--tlsCertificateKeyFile
Para utilizar tanto para la autenticación del cliente como para la autenticación de membresía, el certificado certificate key file debe:
Omite
extendedKeyUsageoEspecifica
extendedKeyUsage = serverAuth, clientAuth