¿Cómo cifra Atlas mis datos?
Por defecto, Atlas cifra todo el almacenamiento de clúster y los volúmenes de snapshot en reposo mediante el Estándar de cifrado avanzado (AES)-256. Su proveedor de nube automatiza este cifrado de disco y gestiona las llaves de cifrado.
Atlas también requiere TLS cifrado para los datos del cliente y las comunicaciones de red dentro del clúster.
Si tu organización necesita información más específica sobre el cifrado de Atlas, comunícate con Atlas soporte de MongoDB:
En Atlas, diríjase a la página Support.
Si aún no se muestra, selecciona la organización deseada en el menú Organizations de la barra de navegación.
Haga clic en el icono Support en la barra de navegación.
Haga clic en View plan.
Aparece la página de soporte.
¿Puedo desactivar TLS en mi implementación?
No.
¿Qué versiones de TLS admite Atlas?
Atlas requiere conexiones TLS para todos los clústeres de Atlas. Atlas admite las versiones 1.2 y 1.3 del protocolo TLS.
IMPORTANTE: Atlas ya no admite TLS 1.0 o 1.1. Todos los clústeres rechazan los intentos de conexión con TLS 1.0 o 1.1. Establezca la versión mínima de TLS de sus clústeres en 1.2 o superior.
Puede leer más sobre el cronograma y los motivos del cambio en la industria de tarjetas de pago (PCI) así como en el Instituto Nacional de Estándares y Tecnología (NIST).
Si tienes preguntas sobre el soporte de TLS o no puedes actualizar tus aplicaciones para soportar TLS 1.3, por favor contacta a Atlas Soporte de MongoDB.
Para abrir un ticket de soporte de Atlas:
En Atlas, diríjase a la página Support.
Si aún no se muestra, selecciona la organización deseada en el menú Organizations de la barra de navegación.
Haga clic en el icono Support en la barra de navegación.
Haga clic en View plan.
Aparece la página de soporte.
¿Cómo sé si mis aplicaciones admiten TLS 1.3?
Las aplicaciones cuyos lenguajes de programación subyacentes o librerías de seguridad sean anteriores a TLS 1.3 pueden requerir actualizarse a una versión más reciente para admitir TLS 1.3. También puede ser necesario actualizar el sistema operativo host de la aplicación para admitir TLS 1.3.
MongoDB y Atlas no proporcionan servicios para auditar aplicaciones externas respecto a qué versiones de TLS son compatibles. Los servicios de terceros, como howsmyssl.com, pueden proporcionar las herramientas adecuadas. MongoDB no respalda este servicio, y su mención es solo informativa. Usa los procedimientos de tu organización para seleccionar el proveedor o servicio para auditar tus aplicaciones.
¿Qué debo hacer para actualizar mis clústeres para TLS 1.3?
Audite sus aplicaciones para el soporte de TLS 1.3.
Actualiza todos los componentes de tu pila tecnológica que no sean compatibles con TLS 1.3.
Modifique la configuración de su clúster para usar TLS 1.3.
Si tiene una configuración de cifrado TLS 1.2 personalizada, debe actualizar la configuración para incluir los cifrados TLS 1.3.
¿Qué entidad certificadora firma los certificados TLS de MongoDB Atlas?
Los certificados TLS de los nodos del clúster de Atlas están firmados por Google Trust Services o Let's Encrypt para mejorar la alta disponibilidad. Atlas utiliza ambas autoridades de certificación simultáneamente. Debe agregar certificados de CA para la autoridad de certificación raíz GTS Root R1, GTS Root R2, GTS Root R3 y GTS Root R4 de Google Trust Services a los almacenes de certificados de confianza de sus clientes, además de la autoridad de certificación raíz ISRG Root X1 de Let's Encrypt para garantizar la continuidad del servicio sin interrupciones.
Atlas utiliza los certificados CA raíz GTS Root R3 y GTS Root R4 para el soporte de TLS 1.3.
Nota
La mayoría de los entornos de aplicaciones ya tienen Let's Encrypt y Google Trust Services en su lista de CA de confianza.
Para descargar los certificados de la Autoridad de Certificación, consulte el repositorio de Servicios de confianza de Google y ISRG Root X1.
Nota
Atlas rota automáticamente los certificados. No necesitas ejecutar el comando rotateCertificates. Utiliza el comando rotateCertificates solo si deseas rotar los certificados manualmente.
¿Con qué frecuencia rota un Clúster de Atlas los certificados TLS?
Los certificados TLS son válidos durante 90 días desde el día en que se emiten. Los certificados se rotan 42 días antes de la fecha de vencimiento del certificado.
Utiliza el siguiente comando para comprobar la fecha de expiración de tu certificado TLS de un nodo:
echo | openssl s_client -showcerts -connect $HOSTNAME:$PORT 2> /dev/null | openssl x509 -noout -enddate
Autoridad de certificación codificada
No se recomienda codificar de manera rígida o fijar certificados intermedios porque puede suponer una carga operativa y un riesgo de disponibilidad. Si Let's Encrypt o Google Trust Services rota o reemplaza tu certificado intermedio fijado, es posible que tu aplicación no se conecte, lo que puede provocar una Interrupción del servicio.
Si debe fijar un certificado, hágalo a los certificados de la Autoridad de certificación y no a cualquier certificado intermedio.
Usuarios de Java
El certificado raíz ISRG de Let's Encrypt y los certificados raíz de Google Trust Services están disponibles en el almacén de confianza por defecto de Java versión 7 después de la actualización 7u391 y Java versión 8 después de la actualización 8u381 . Utilice una versión de Java posterior al 18 de julio de 2023.
Asegúrese de que el software cliente de Java esté actualizado. Utilice las últimas versiones de Java para aprovechar las mejoras más allá de estos nuevos requisitos de la Autoridad de Certificación para nuestros certificados TLS.
Si cuentas con tu propio almacén de confianza, añade los certificados de Let's Encrypt y Google Trust Services. Para obtener más información, consulte ¿Qué entidad emisora de certificados firma los certificados TLS de MongoDB Atlas?
Usuarios de Windows servidor
La autoridad de certificación raíz ISRG Root X1, GTS Root R1 y GTS Root R2 no están incluidas por defecto en Windows servidor, pero están disponibles en el Microsoft Trusted Root Program.
Para configurar Windows Server para descargar certificados raíz confiables, consulte Documentación de Windows.
Usuarios de Amazon Linux AMI
Algunas versiones de Amazon Linux AMI pueden no tener tanto ISRG Root X1 como GTS Root R1 y certificados R2 . Por favor, migre a una versión más reciente de Amazon Linux para obtener los certificados raíz requeridos. Después del 2025 de junio, se requerirá el soporte de los certificados ISRG Root X1, GTS Root R1 y R2 para Atlas a fin de evitar problemas de compatibilidad de certificados.
Si necesitas usar una AMI Amazon Linux antigua, instala manualmente la Autoridad Certificadora raíz ISRG Root X1, GTS Root R1 y R2.
Todos los demás
Este cambio no debería tener un impacto en ti si usas un lenguaje de programación reciente y una versión del sistema operativo actualizada.
¿Por qué falló mi cambio de configuración TLS con un UNSAFE_TLS_TRANSITION error?
Atlas impide que los cambios de configuración de TLS interrumpan la comunicación entre los nodos del clúster durante una actualización progresiva.
Cuando actualizas la configuración de TLS, Atlas aplica los cambios de un nodo a la vez. Durante este proceso, los nodos que ejecutan la configuración anterior deben poder conectarse a los nodos que ejecutan la nueva configuración. Si los cambios propuestos remueven todas las versiones de TLS o los conjuntos de cifrado compartidos, los nodos no podrán comunicarse, lo que provocará un clúster particionado y un posible tiempo de inactividad.
Para proteger la disponibilidad del clúster, Atlas bloquea estas transiciones inseguras y devuelve el error UNSAFE_TLS_TRANSITION.
UNSAFE_TLS_TRANSITION Causas de error
Este error suele producirse en los siguientes escenarios cuando no hay superposición entre las configuraciones de TLS actuales y propuestas:
Incompatibilidad de la versión de TLS.
Ejemplo: Cambio directo de solo TLS 1.2a solo TLS 1.3.
Resultado: Los nodos que usan TLS 1.2 no pueden conectarse a los nodos que requieren TLS 1.3.
Desajuste de suite de cifrado.
Ejemplo: Reemplazar todas las suites de cifrado existentes con un set completamente diferente.
Resultado: Los nodos no tienen un cifrado compartido para negociar una conexión
UNSAFE_TLS_TRANSITION Solución de errores
Realice los cambios de TLS en fases y asegúrese de que haya superposición entre la configuración antigua y la nueva:
Para las versiones de TLS:
Habilita TLS 1.2 y TLS 1.3.
Aplique el cambio y permita que la actualización se complete.
Remover TLS 1.2 en una actualización de seguimiento (si lo desea).
Para suites de cifrado:
- Asegúrese de que se comparta al menos un conjunto de cifrado entre las configuraciones actuales y nuevas durante la transición.
UNSAFE_TLS_TRANSITION Error Puntos clave
Evite los cambios de TLS "todo a la vez". Mantenga siempre la compatibilidad temporal entre las configuraciones antiguas y nuevas para garantizar actualizar progresivamente de forma segura.
¿Cuál es la política de soporte de Atlas para los drivers de Community y no compatibles?
Atlas proporciona diferentes niveles de soporte para los driver oficialmente compatibles, los driver de la Community y las configuraciones no compatibles.
Categorías de driver
Driver oficialmente compatibles
MongoDB desarrolla y mantiene estos drivers, que se enumeran en mongodb.com/es/docs/drivers. La matriz de pruebas, el proceso de lanzamiento y el SLA de soporte de MongoDB cubren estos drivers.
Los driver oficialmente compatibles incluyen C, C++, C#, Go, Java, Kotlin, Node.js, PHP, Python, Ruby, Rust, Scala y Swift.
Community drivers
Los desarrolladores de terceros crean y mantienen estos drivers, que implementan las especificaciones publicadas o el protocolo de conexión de MongoDB. Los ejemplos incluyen Zookzook (Elixir), Mango (Dart), mongolite (R) y mgo (Go).
Configuraciones no admitidas
Cualquier driver compatible oficialmente o Community utilizado en una versión de fin de vida útil.
Niveles de soporte
Driver oficialmente compatibles (versión actual)
El SLA de Atlas cubre estos drivers. MongoDB proporciona resolución y solución de problemas estándar, incluida la investigación y las correcciones de problemas de conexión.
Driver oficialmente compatibles (versión EOL)
MongoDB proporciona soporte de mejor esfuerzo. MongoDB investiga los problemas, pero podría recomendar la actualización a una versión actual.
Community drivers
MongoDB proporciona soporte de diagnóstico en la medida de lo posible. El servicio de soporte le ayuda a determinar si el problema se origina en la plataforma o en el controlador. Para problemas relacionados con el controlador, MongoDB proporciona orientación y le remite al responsable del mantenimiento del controlador. MongoDB no depura ni aplica parches al código de los Community driver.
Responsabilidades
¿Qué |servicio|
Atlas realiza evaluaciones de riesgos para los cambios de plataforma que afectan la capa de conexión, incluidos los cambios de versión de TLS, las rotaciones de certificados y las actualizaciones del mecanismo de autenticación. Atlas evalúa los patrones de fragilidad conocidos incluso cuando la fragilidad se origina en el código del lado del cliente.
Para los cambios de plataforma de alto riesgo, Atlas publica orientación en notas de versión y notificaciones previas al mantenimiento cuando sea posible.
Qué |service| no hace
Atlas no:
Probar, certificar o garantizar la corrección de los drivers de la Community
Pruebe todos los driver de la Community en todas las configuraciones.
Compromiso de aplicar parches, hacer revisión o mantener los drivers de Community
Los Community drivers deben implementar correctamente la negociación de TLS, la autenticación, el protocolo de conexión y el comportamiento de conmutación por error. Cualquier contribución que MongoDB haga a los drivers de la Community es voluntaria, no una obligación contractual.
Cobertura de SLA
El SLA de Atlas cubre solo los drivers de MongoDB oficialmente compatibles en las versiones actuales. Las interrupciones del servicio causadas por errores del driver de Community o configuraciones de driver no compatibles quedan fuera del SLA.
Utilice drivers compatibles oficialmente en las versiones actuales para obtener una cobertura completa del SLA y la mejor experiencia de soporte.