MongoDB Atlas admite diversos métodos de autorización para garantizar un acceso robusto a los recursos. Atlas requiere que todos los usuarios se autentiquen. Una vez autenticado, la autorización determina su acceso a los recursos.
Al implementar la autorización Atlas, debe utilizar Control de acceso basado en roles (RBAC). El uso de 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.
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 puedes asignar: nivel de organización y nivel de proyecto.
Roles a nivel de la organización
Las cuentas de servicio utilizan los roles a nivel de organización para automatizar tareas como la creación de nuevos proyectos, la gestión de IAM y la facturación. También pueden utilizarse para los miembros 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
Organization Memberdebe ser para administradores del equipo de operaciones y plataforma que puedan ver la configuración y los ajustes 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 que se utiliza para extraer facturas programáticamente de la API de facturación e incorporarlas a su herramienta FinOps. Esta misma cuenta de servicio debe tener acceso a todas las organizaciones vinculadas de las que es responsable de informar sobre el 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.
Deberías usar un Proveedor de Identidad Federada moderno (FIP) que proporcione SSO, como Azure Entra ID, Okta o Ping Identity. Esto hace que el proceso de autorización sea más seguro y respalda la flexibilidad necesaria para asignar programáticamente grupos de proveedores de identidad a roles de Atlas. Debería restringir el acceso al dominio de su empresa, lo que impide 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 grupos de proveedores de identidad federada, consulte 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 obtener ejemplos de configuración de autorización, consulte Ejemplos de autorización y autenticación.