MongoDB Atlas admite una variedad de métodos de autorización para garantizar un acceso sólido a los recursos. Atlas requiere que todos los usuarios se autentiquen. Una vez que el usuario está autenticado, la autorización determina el acceso del usuario a los recursos.
Al implementar la autorización de Atlas, debes usar Control de Acceso Basado en Roles (RBAC). El uso de los grupos de usuarios de un Proveedor de Identidad Federada con RBAC simplifica la gestión.
Las siguientes recomendaciones se aplican tanto a los usuarios de la fuerza laboral (humanos) como a los usuarios de la carga de trabajo (aplicaciones) en todos paradigmas de implementación.
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 el Modelo de Responsabilidad Compartida.
RBAC y roles predefinidos
Atlas utiliza el control de acceso basado en roles (RBAC) para simplificar la gestión de la autorización de usuarios. Atlas incluye roles de usuario predefinidos que proporcionan niveles específicos de acceso comúnmente necesarios para gestionar Atlas con la interfaz de usuario y las API. Para simplificar la gestión, puedes luego asignar los roles a proveedor de identidad groups.
Para conectarse a clústeres de Atlas, utilice roles de base de datos personalizados de grano fino para proporcionar un alcance granular en función del acceso requerido para que el rol realice su función. Este enfoque permite seguir el principio de mínimo privilegio.
Nota
Siempre debe restringir el acceso asignando los roles RBAC con menor nivel necesario. También deberías usar restricciones de dominio.
Hay dos niveles de roles que puede asignar: a nivel de organización y a nivel de proyecto.
Roles a nivel de la organización
Las cuentas de servicio utilizan roles a nivel de organización para automatizar tareas como la creación de nuevos proyectos, la gestión de IAM y la gestión de facturación. También pueden usarse para los nodos del equipo de la plataforma.
La
Organization Ownerel rol debe estar fuertemente restringido y no asignarse a un humano, ya que tiene la capacidad de cambiar la configuración a nivel organizacional y borrar configuraciones. Este rol debe asignarse a una cuenta de servicio que sólo utilice para configurar y configurar inicialmente la organización. Minimiza los cambios de configuración después de la creación inicial. Para evitar bloqueos de cuenta, puedes crear los siguientes elementos:Grupo de Propietario de Organización SAML con acceso Just-in-Time.
Cuenta de servicio con el rol de propietario de la organización. Mantenlo en un lugar seguro con una gestión de acceso estricta para escenarios de emergencia de ruptura de cristal.
El rol de
Organization Memberdebe estar destinado a los administradores en el equipo de operaciones y plataforma, quienes pueden ver la configuración y las opciones de la organización.El rol de
Organization Project Creatordebe ser una cuenta de servicio programática utilizada para crear proyectos en nombre de nuevas aplicaciones para los equipos de desarrollo y de producto.El rol
Organization Billing Admindebe ser una cuenta de servicio programática utilizada para obtener facturas de forma programática de la API de facturación e introducirlas en la herramienta FinOps. Esta misma cuenta de servicio debería tener acceso a todas las organizaciones vinculadas de las que es responsable de generar reportes de uso.
Roles a nivel de proyecto
Los roles a nivel de proyecto son para los equipos de desarrollo, pruebas y producto responsables del desarrollo de aplicaciones y mantenimiento. Al igual que con los roles a nivel de organización, siempre se debe seguir el principio de mínimo privilegio. Por ejemplo, el rol Project Owner solo debe ser utilizado para la gobernanza aplicada por el equipo de operaciones y provisionamineto. Debido a que un propietario del Proyecto puede crear y borrar clústeres, debes asignar este rol a una cuenta de servicio programática a menos que estés trabajando en un entorno aislado.
Para obtener más información sobre los roles a nivel de proyecto, consulte:
Proveedores de identidad federados
Al integrar Atlas con un proveedor de identidad federado, puede utilizar el provisionamineto justo a tiempo asignando los grupos del proveedor de identidad a los roles de Atlas. Esto agiliza la gestión de acceso y garantiza la seguridad y la organización en la asignación de roles a lo largo y ancho de la plataforma. Puedes conceder acceso programáticamente en función del proceso de provisionamineto de tu capa de orquestación.
Debes usar un proveedor de identidad federada moderno (FIP) que ofrezca SSO, como Azure Entra ID, Okta o Ping Identity. Esto hace que el proceso de autorización sea más seguro y admite la flexibilidad necesaria para asignar programáticamente grupos de proveedor de identidad a roles de Atlas. Debes restringir el acceso al dominio de tu empresa, lo que evita que los usuarios inicien sesión en Atlas cuando no están autorizados para acceder.
Para obtener más información sobre cómo asignar roles a los grupos de proveedores de identidad federados, consulta Proceso de asignación de roles.
Acceso justo a tiempo
Atlas también admite la creación de usuarios temporales de base de datos que expiran automáticamente después de los tiempos predefinidos. Se puede crear un usuario por 6 horas, 1 día o 1 semana.
Para obtener más información, consulta Configurar los usuarios de base de datos.
Ejemplos
Para ver ejemplos de cómo configurar la autorización, consulte Ejemplos de autorización y autenticación.