TLS cifra las conexiones entre los clientes y su implementación de MongoDB, así como entre los nodos de un conjunto de réplicas. Antes de configurar TLS, utilice esta página para decidir la configuración que mejor se adapte a sus requisitos de seguridad.
Importante
Estos pasos se aplican a las implementaciones de MongoDB autogestionadas. Los clústeres de MongoDB Atlas utilizan TLS de forma predeterminada. Si utiliza Cloud Manager u Ops Manager, configure TLS a través de su herramienta de gestión de implementaciones.
Antes de comenzar
Antes de planificar la configuración de TLS, asegúrese de tener los siguientes recursos e información:
Un conjunto de réplicas de MongoDB autogestionadas para configurar con TLS.
El tipo de autoridad de certificación disponible para usted, como una CA pública o privada.
Sus requisitos de seguridad, como por ejemplo si necesita Autenticación X.509.
El tipo de CA a la que tenga acceso determina qué configuraciones TLS estarán disponibles para usted:
Tipo CA | Descripción | Uso recomendado |
|---|---|---|
CA pública |
| Cifrado TLS intraclúster sin autenticación mTLS o X.509 |
CA privada |
| Autenticación de nodos mTLS y X.509 dentro del clúster |
Firmado por el autor |
| Desarrollo y pruebas únicamente a nivel local. |
Elige tu configuración
Las siguientes secciones le ayudarán a decidir cómo configurar el cifrado y la autenticación TLS entre los nodos de un conjunto de réplicas, y entre los clientes y el servidor.
Ejemplo de implementación con TLS intraclúster y autenticación de archivo de clave entre nodos, y TLS mutuo y autenticación X.509 entre cliente y servidor.
Cifrado entre nodos
Todas las implementaciones con TLS habilitado cifran las conexiones entre nodos. También puede habilitar mTLS dentro del clúster, 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 establece una conexión saliente con otro nodo, su comportamiento depende de si se habilita mTLS dentro del clúster.
Utilice la siguiente tabla para determinar lo que necesita para cada modo de cifrado:
Modo de cifrado | Requisitos del sistema |
|---|---|
TLS intraclúster sin mTLS |
|
mTLS intraclúster |
|
Sin mTLS intraclúster, los nodos no presentan un certificado para autenticarse como cliente en las conexiones salientes. El nodo que se conecta verifica el certificado del servidor del nodo receptor, pero este último no verifica la identidad del nodo que se conecta mediante el protocolo de enlace TLS. Utilice esta configuración si solo puede obtener certificados con una serverAuth EKU, por ejemplo, a través de una CA pública. No puede habilitar la509 autenticación X. entre nodos con esta configuración.
Con mTLS intraclúster, cada nodo también presenta un certificado en las conexiones salientes a otros nodos, lo que proporciona verificación de identidad mutua. Se requiere mTLS intraclúster para usar la autenticación de nodo X.509. Sin embargo, dado que requiere certificados con la EKU clientAuth, debe tener acceso a una CA privada.
Autenticación entre nodos
Los miembros del conjunto de réplicas se autentican entre sí para confirmar que solo los miembros autorizados participan en la replicación. De forma predeterminada, los conjuntos de réplicas con autorización habilitada utilizan la autenticación mediante archivo de clave entre nodos. Sin embargo, si habilita mTLS dentro del clúster, puede utilizar la autenticación mediante certificado X.509.
Utilice la siguiente tabla para determinar lo que necesita para cada modo de autenticación:
Modo de autenticación | Requisitos del sistema |
|---|---|
autenticación de archivo de clave |
|
Autenticación de nodo X.509 |
|
Si utiliza la autenticación mediante archivo de clave, todos los miembros del conjunto de réplicas comparten un único secreto almacenado en dicho archivo. Cada nodo demuestra su pertenencia al conjunto presentando el secreto compartido al conectarse con otros nodos. Dado que todos los nodos comparten la misma clave, si desea revocar el acceso de un nodo individual, deberá reemplazar el archivo de clave en todos los nodos.
La autenticación X.509 utiliza el certificado de clúster de cada nodo para verificar su pertenencia. Dado que el intercambio de certificados se produce durante el protocolo de enlace TLS, la autenticación de nodos X.509 requiere mTLS dentro del clúster para que los nodos verifiquen su identidad mutuamente. La identidad de certificado única de cada nodo permite revocar el acceso de un nodo individual mediante la revocación de su certificado, sin afectar a los demás nodos. Además, la autenticación y el cifrado se establecen conjuntamente en un único protocolo de enlace.
Los certificados de los miembros del clúster deben incluir509 atributos X. que los distingan de los certificados de cliente habituales. Para obtener información sobre los atributos de certificado necesarios, consulte Certificado X. de509 miembro.
Cifrado entre cliente y servidor
Cuando un cliente como mongosh o cuando un controlador se conecta a una mongod instancia habilitada para TLS, el servidor presenta su certificado para probar 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 es exitosa, TLS cifra la conexión entre el servidor y el cliente.
Utilice la siguiente tabla para determinar lo que necesita para cada modo de cifrado:
Modo de conexión | Requisitos del sistema |
|---|---|
TLS sin certificado de cliente |
|
Autenticación mutua de cliente TLS o X.509 | El cliente debe presentar un certificado con |
Puedes allowConnectionsWithoutCertificates true configurar a para que el cliente se conecte sin enviar un certificado. Al habilitar esta opción, se evita que los usuarios se conecten con certificados incorrectos, como aquellos que solo incluyen la serverAuth EKU. El servidor cifra la conexión y demuestra su identidad al cliente, pero no puede verificar la identidad del cliente mediante el 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 verificarlo con una autoridad de certificación (CA) de confianza. Esto establece una conexión TLS mutua 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 diversas maneras, pero esta guía de inicio rápido cubre la509 autenticación SCRAM y X..
Utilice la siguiente tabla para determinar lo que necesita para cada modo de autenticación:
Modo de autenticación | Requisitos del sistema |
|---|---|
Autenticación SCRAM |
|
Autenticación del cliente X.509 |
|
MongoDB utiliza SCRAM como mecanismo de autenticación de cliente predeterminado. 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 del cliente X.509 utiliza el certificado que el cliente presenta durante la conexión. Una vez establecida la autenticación TLS mutua, el cliente se autentica en la base de datos $external mediante el mecanismo MONGODB-X509. MongoDB asigna el campo de sujeto del certificado a un usuario en la base de datos $external.
Próximos pasos
Una vez que haya determinado su configuración utilizando esta página, continúe con la obtención de certificados de servidor TLS.