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 de la carga de trabajo (aplicaciones) en todos los entornos. 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 administrar Atlas con la interfaz de usuario y las API. Para simplificar la gestión, puede asignar los roles a... Gruposde desplazados internos.
Para conectarse a clústeres de Atlas, utilice roles de base de datos personalizados y detallados para proporcionar un alcance granular según el acceso necesario para que el rol realice su función. Este enfoque le permite seguir el principio de mínimo privilegio.
Nota
Siempre debe restringir el acceso asignando los roles RBAC menos necesarios. También debe usar restricciones de dominio.
Hay dos niveles de roles que puedes asignar: nivel de organización y nivel de proyecto.
Roles a nivel de 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.
El
Organization OwnerEl rol debe estar muy restringido y no debe asignarse a una persona, ya que puede modificar la configuración de toda la organización y eliminarla. Este rol debe asignarse a una cuenta de servicio que se use únicamente para la configuración inicial de la organización. Minimice los cambios de configuración después de la creación inicial. Para evitar el bloqueo de cuentas, puede crear los siguientes elementos:Grupo propietario de la organización SAML con acceso Just-in-Time.
Cuenta de servicio con el rol de Propietario de la Organización. Manténgala en un lugar seguro con una gestión de acceso robusta para situaciones de emergencia.
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
Organization Project Creatordebe ser una cuenta de servicio programático utilizada para crear proyectos en nombre de nuevas aplicaciones para los equipos de desarrollo y 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 y mantenimiento de aplicaciones. Al igual que con los roles a nivel de organización, siempre se debe seguir el principio de mínimos privilegios. Por ejemplo, el rol Project Owner solo debe usarse para la gobernanza implementada por el equipo de operaciones y aprovisionamiento. Dado que el propietario del proyecto puede crear y eliminar clústeres, se debe asignar este rol a una cuenta de servicio programática, a menos que se trabaje en un entorno de pruebas.
Para obtener más información sobre los roles a nivel de proyecto, consulte:
Proveedores de identidad federada
Al integrar Atlas con un proveedor de identidad federado, puede usar el aprovisionamiento justo a tiempo asignando grupos de proveedores de identidad a roles de Atlas. Esto agiliza la gestión del acceso y garantiza la asignación segura y organizada de roles en toda la plataforma. Puede otorgar acceso programáticamente según el proceso de aprovisionamiento de su capa de orquestación.
Debe usar un proveedor de identidad federada (FIP) moderno que proporcione SSO, como Azure Entra ID, Okta o Ping Identity. Esto aumenta la seguridad del proceso de autorización y proporciona la flexibilidad necesaria para asignar programáticamente grupos de IdP a roles de Atlas. Debe restringir el acceso al dominio de su empresa, lo que impide que los usuarios inicien sesión en Atlas sin autorización.
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 permite la creación de usuarios temporales de bases de datos que caducan automáticamente tras un periodo predefinido. Un usuario puede crearse por 6 horas, 1 días o 1 semanas.
Para obtener más información, consulte Configurar usuarios de la base de datos.
Ejemplos
Para obtener ejemplos de configuración de autorización, consulte Ejemplos de autorización y autenticación.