MongoDB Atlas admite una variedad de métodos de autenticación para garantizar una seguridad robusta. Atlas requiere que todos los usuarios se autentiquen para acceder a la Interfaz de Usuario de Atlas, a las bases de datos de Atlas y a la API de administración de Atlas.
Nota
El Modelo de Responsabilidad Compartida de MongoDB Atlas define los deberes complementarios de MongoDB y sus clientes en el mantenimiento de un entorno de datos seguro y resiliente. Bajo este marco, MongoDB gestiona la seguridad y la integridad operativa de la plataforma subyacente, mientras que los clientes son responsables de la configuración, gestión y políticas de datos de sus implementaciones específicas. Para obtener un desglose detallado de la propiedad en materia de seguridad y excelencia operativa, consulta Modelo de responsabilidad compartida.
Nota
En este contexto, un "usuario" puede ser un humano o una aplicación. Nos referimos a usuarios humanos como "Workforce Identity" y a las aplicaciones como "Workload Identity".
Dos factores determinan los tipos de autenticación que se deben utilizar:
El tipo de identidad (humano o máquina)
El recurso al que la identidad necesita acceso. El recurso puede ser uno de los siguientes: Atlas Interfaz de Usuario, Atlas base de datos o Atlas APIs.
Autenticación de Atlas Interfaz de Usuario
Usuarios de Workforce
Utiliza restricciones de acceso por IP y luego:
Utilice autenticación federada con un proveedor de identidad SAML 2.0, como Okta, Microsoft Entra ID o Ping Identity, y
Utiliza las credenciales de Atlas con Autenticación multifactor (MFA). Siempre debes usar la forma más segura de MFA disponible, como una clave de hardware o biometría.
Usuarios de carga de trabajo
Esto solo aplica a los usuarios de Workforce.
Autenticación de la base de datos Atlas
Usuarios de Workforce
Utilice Federación de identidad de la fuerza laboral.
Para entornos de desarrollo y pruebas, también puedes utilizar SCRAM. Considera crear usuarios temporales de bases de datos con acceso a la base de datos justo a tiempo.
Usuarios de carga de trabajo
con uno de los siguientes:
Para los entornos de desarrollo y prueba, también puede utilizar certificados X.509 o SCRAM.
Autenticación de la API de Atlas
Nota
Esto aplica tanto a los usuarios de Workforce como a los de carga de trabajo.
Usa las Cuentas de servicio. Para entornos de desarrollo y prueba, también puede utilizar Cuentas de servicio o Claves API.
Tipos de autenticación
Las siguientes secciones proporcionan detalles sobre los métodos de autenticación usados para acceder a la interfaz de usuario de Atlas, la base de datos de Atlas o la API de administración de Atlas.
Autenticación federada
La autenticación federada permite administrar todas las autenticaciones en la Interfaz de Usuario de Atlas en los distintos sistemas y aplicaciones a través de un proveedor de identidad central, lo que reduce la complejidad de la gestión de usuarios. Con la autenticación federada, puedes aplicar políticas de seguridad como complejidad de contraseñas, rotación de credenciales y MFA dentro de las herramientas del proveedor de identidad.
Para la interfaz de usuario de Atlas, puedes utilizar cualquier proveedor de identidad compatible con SAML como Okta, Microsoft Entra ID o Ping Identity.
Federación de identidad de fuerza laboral
Workforce Identity Federation te permite gestionar toda la autenticación a la base de datos de Atlas a través de tu proveedor de identidades. Para aprender más, mira Configurar Workforce Identity Federation con OIDC.
Federación de identidad de carga de trabajo
La carga de trabajo Identity Federation permite que las aplicaciones que se ejecutan en entornos de nube como Azure y Google Cloud se autentiquen con Atlas sin necesidad de gestionar credenciales de usuario de base de datos independientes. Con la carga de trabajo Identity Federation, se pueden gestionar los usuarios de la base de datos de Atlas mediante las identidades gestionadas por Azure, cuentas de servicio de Google o cualquier servicio compatible con OAuth 2.0. Estos mecanismos de autenticación simplifican la gestión y mejoran la seguridad al permitir el acceso sin contraseña a la base de datos de Atlas.
Autenticación con el rol de IAM de AWS
También puedes autenticarte a través de AWS IAM roles. Para obtener más información, consulta Autenticación AWS IAM.
Para aprender más, se puede consultar Configurar la federación de identidades de carga de trabajo con OAuth 2.0 y Configurar la autenticación federada.
Autenticación de Múltiples Factores
Para cualquier usuario humano que tenga acceso al plano de control de Atlas, requerimos MFA para mayor seguridad. Atlas es compatible con los siguientes métodos MFA como identificaciones secundarias:
Claves de seguridad
Biométrico
Autenticadores OTP
Notificaciones push con Okta Verify
Correo electrónico
Nota
Si usas Federated Auth, configure y gestione MFA en el proveedor de identidad. Si usa credenciales de Atlas, MFA se configura y administra dentro de Atlas. Se requiere MFA al utilizar credenciales de Atlas.
Para obtener más información, consulta Gestiona tus opciones de autenticación multifactorial.
Certificados de cliente X.509
Los certificados X.509 brindan la seguridad de TLS mutuo, haciéndolos aptos para entornos de staging y producción, y puedes utilizar tu propia autoridad certificadora con X.509. La desventaja de X.509 es que debes gestionar los certificados y la seguridad de estos certificados del lado de la aplicación, mientras que Workload Identity Federation permite acceso sin contraseña y una seguridad de la aplicación más sencilla.
Para obtener más información, consulta X.509.
Autenticación de contraseña SCRAM
Los clústeres Atlas admiten la autenticación de contraseña SCRAM para la autenticación de usuarios, pero recomendamos SCRAM solo para usar en entornos de desarrollo y prueba.
Si aprovecha509 la autenticación X. o SCRAM, le recomendamos que utilice un gestor de secretos de terceros como HashiCorp Vault. o AWS Secrets Manager para generar y almacenar credenciales de bases de datos complejas.
Para obtener más información, vea SCRAM.
Cuentas de servicio
Las cuentas de servicio utilizan el estándar de la industria OAuth2.0 para autenticar de forma segura con Atlas a través de la API de Administración de Atlas. Recomendamos que utilices cuentas de servicio en lugar de claves API cuando sea posible, ya que proporcionan mayor seguridad a través de tokens de acceso de corta duración y la rotación obligatoria de credenciales.
Puedes gestionar el acceso programático para cuentas de servicios mediante la Atlas Interfaz de Usuario, Atlas CLI, Atlas Administration API y Terraform.
Claves de API
Las cuentas de servicio son el método preferido de autenticación. Atlas proporciona soporte heredado para la autenticación basada en claves de API para gestionar el acceso programático. La autenticación basada en claves de API utiliza HTTP Digest authentication para proteger las solicitudes.
Para mejorar aún más la seguridad y minimizar el riesgo de acceso no autorizado:
Sigue las mejores prácticas para rotar las claves API regularmente. Para saber cómo rotar estas claves con HashiCorp Vault, consulta, por ejemplo, la documentación de Hashicorp.
Utiliza la lista de acceso IP para tus claves API. Para obtener más información, consulte Requerir una Lista de Acceso IP para la API de administración de Atlas.
Para obtener más información, consulta Métodos de autenticación de la API de administración de Atlas.
Gestión de secretos
Recomendamos utilizar un gestor de secretos de terceros como HashiCorp Vault o AWS Secrets Manager para generar y almacenar credenciales complejas de bases de datos. Un gestor de secretos puede generar credenciales de base de datos de manera dinámica según los roles configurados para las bases de datos de Atlas.
Para aprender más, consulta el blog Gestiona los secretos de MongoDB Atlas base de datos en HashiCorp Vault.
Implementaciones
Para aprender nuestras recomendaciones para implementaciones relacionadas con la autenticación, consulta la Orientación para Organizaciones, Proyectos y Clústeres de Atlas.
Medidas adicionales de seguridad
Para mejorar aún más la seguridad y minimizar el riesgo de acceso no autorizado, considera estas medidas de seguridad adicionales:
Rota los secretos de las cuentas de servicio antes de que caduquen.
Utiliza una lista de acceso IP para tus cuentas de servicio.
Asignar el rol de Atlas menos privilegiado requerido para el propósito previsto de la cuenta de servicio, con el fin de adherirse al principio de mínimo privilegio.
Para obtener más información, consulta la Descripción general de las cuentas de servicio.