Planifique su configuración de TLS para implementaciones autogestionadas

Cifrado entre nodos

Todas las implementaciones habilitadas para TLS cifran las conexiones entre nodos. También puede habilitar intra-clúster mTLS, lo que requiere que los nodos presenten certificados para autenticarse como clientes durante el protocolo de enlace TLS. Cuando un nodo acepta una conexión entrante, presenta su certificado de servidor para que la parte que se conecta pueda verificar su identidad. Cuando un nodo realiza una conexión saliente a otro nodo, su comportamiento depende de si habilita mTLS intraclúster.

Utilice la siguiente tabla para determinar lo que necesita para cada moda de cifrado:

Sin mTLS intraclúster, los nodos no presentan un certificado para autenticarse como cliente en las conexiones salientes. El nodo de conexión verifica el certificado del servidor del nodo receptor, pero el nodo receptor no verifica la identidad del nodo de conexión a través del protocolo de enlace TLS. Utilice esta configuración si solo puede obtener certificados con un EKU serverAuth, como a través de una CA pública. No puede habilitar la autenticación X.509 entre nodos con esta configuración.

Con mTLS dentro del clúster, cada nodo también presenta un certificado en las conexiones salientes a otros nodos, lo que proporciona una verificación de identidad mutua. Se requiere mTLS dentro del clúster para utilizar la autenticación de nodo X.509. Sin embargo, debido a que requiere certificados con el EKU clientAuth, debe tener acceso a una CA privada.

Autenticación entre nodos

Los sets de réplicas se autentican entre sí para confirmar que solo los nodos autorizados participan en la replicación. Por defecto, los sets de réplicas habilitados para autorización utilizan la autenticación de archivo de llave entre nodos. Sin embargo, si habilita mTLS dentro del clúster, puede utilizar la autenticación de certificado X.509 en su lugar.

Utiliza la siguiente tabla para determinar lo que necesitas para cada moda de autenticación:

Si utiliza la autenticación de archivo de claves, todos los nodos del set de réplicas comparten un único secreto almacenado en un archivo de claves. Cada nodo demuestra su pertenencia presentando el secreto compartido cuando se conecta a otros nodos del conjunto. Dado que todos los nodos comparten la misma clave, si desea revocar el acceso de un nodo individual, debe reemplazar el archivo de claves en todos los nodos.

La autenticación X.509 utiliza el certificado de clúster de cada nodo para verificar la pertenencia. Dado que el intercambio de certificados se produce durante el protocolo de enlace TLS, la autenticación de nodos X.509 requiere mTLS intraclúster para que los nodos tengan una verificación mutua de la identidad. La identidad de certificado única de cada nodo le permite revocar el acceso de un nodo individual revocando su certificado, sin afectar a otros nodos. Además, la autenticación y el cifrado se establecen juntos en un único protocolo de enlace.

Los certificados de los nodos del clúster deben incluir atributos X.509 que los distingan de los certificados de cliente normales. Para aprender sobre los atributos de certificado necesarios, consulta Certificado X.509 de nodo.

Cifrado entre cliente y servidor

Cuando un cliente como mongosh o un driver se conecta a una instancia mongod habilitada para TLS, el servidor presenta su certificado para demostrar su identidad y el cliente verifica el certificado con un certificado de CA de confianza. El cliente también confirma que el nombre de host del servidor coincide con el nombre de host del certificado. Si la verificación se realiza correctamente, TLS cifra la conexión entre el servidor y el cliente.

Utilice la siguiente tabla para determinar lo que necesita para cada moda de cifrado:

Puede establecer allowConnectionsWithoutCertificates en true para permitir que el cliente se conecte sin enviar un certificado. Al habilitar esto, se evita que los usuarios se conecten con certificados incorrectos, como los que solo incluyen el EKU serverAuth. El servidor cifra la conexión y demuestra su propia identidad al cliente, pero el servidor no puede verificar la identidad del cliente a través del protocolo de enlace TLS. El cliente debe autenticarse mediante un método como SCRAM.

Si el cliente presenta su propio certificado durante el protocolo de enlace, el servidor puede verificar el certificado del cliente con una CA de confianza. Esto establece TLS mutuo entre el servidor y el cliente. El cliente debe presentar un certificado para habilitar la autenticación de cliente X.509 entre el cliente y el servidor.

Autenticación entre cliente y servidor

Una vez establecida la conexión TLS, los clientes deben autenticarse para acceder a la implementación. Los clientes pueden autenticarse de muchas maneras, pero esta guía rápida cubre la autenticación SCRAM y X.509.

Utiliza la siguiente tabla para determinar lo que necesitas para cada moda de autenticación:

MongoDB utiliza SCRAM como mecanismo de autenticación de cliente por defecto. El cliente proporciona un nombre de usuario, una contraseña y la base de datos de autenticación, y MongoDB verifica las credenciales con los usuarios de la base de datos especificada. SCRAM no requiere que el cliente presente un certificado durante el protocolo de enlace TLS.

La autenticación de cliente X.509 utiliza el certificado que el cliente presenta durante la conexión. Una vez que se establece TLS mutuo, el cliente se autentica en la base de datos $external utilizando el mecanismo MONGODB-X509. MongoDB asigna el campo de asunto del certificado a un usuario de la base de datos $external.