Novedades en API7 Enterprise: IAM para Control de Acceso Granular

Introducción

Las versiones anteriores de API7 Enterprise proporcionaban un mecanismo de gestión de RBAC (Control de Acceso Basado en Roles) simple, fácil de usar y completo. Este mecanismo garantizaba la seguridad del sistema mientras otorgaba a los usuarios una configuración flexible de permisos basada en roles. A medida que los tipos de recursos y las características de API7 Enterprise han aumentado, la gestión tradicional de RBAC ha revelado gradualmente sus limitaciones en el control granular de permisos. Además, más empresas buscan estrategias de gestión de permisos más refinadas para satisfacer sus necesidades comerciales complejas y cambiantes.

Para mejorar aún más las características de gestión de permisos de API7 Enterprise, hemos actualizado completamente el sistema de permisos de roles existente, introduciendo un modelo de políticas de IAM (Gestión de Identidad y Acceso) más flexible y potente. Este modelo proporciona a los usuarios un control de permisos más granular y una mayor flexibilidad, satisfaciendo mejor las necesidades complejas y variables de gestión de permisos de las empresas modernas.

¿Qué es el Modelo de Políticas IAM?

El modelo de políticas IAM (Gestión de Identidad y Acceso) representa un método más detallado y eficiente de gestión de permisos. Permite a los administradores definir políticas específicas, cada una de las cuales contiene un conjunto de reglas (Statements). Estas reglas especifican en detalle qué usuarios o roles pueden realizar qué acciones sobre qué recursos. En comparación con el mecanismo tradicional de RBAC, este modelo ofrece una mayor flexibilidad y granularidad.

Ventajas de IAM sobre RBAC:

• Control Granular: IAM puede controlar permisos a nivel de recurso e incluso para atributos o operaciones específicas dentro de los recursos, mientras que RBAC a menudo asigna permisos basados en roles, con una granularidad relativamente gruesa.

• Flexibilidad: IAM permite a los administradores gestionar políticas y permisos directamente sin necesidad de crear y gestionar numerosos roles para la asignación indirecta de permisos, lo que hace que la configuración sea más sencilla y flexible.

• Escalabilidad: A medida que las funcionalidades del sistema aumentan y los tipos de recursos se diversifican, IAM puede adaptarse más fácilmente a los cambios añadiendo nuevas políticas para satisfacer nuevas necesidades de permisos, mientras que RBAC puede requerir el ajuste o la adición de numerosos roles para adaptarse a los cambios.

¿Cómo Usar Políticas IAM en API7 Enterprise?

1. Crear Políticas de Permisos

Después de iniciar sesión en API7 Enterprise, haga clic en el botón "Organization" en la esquina superior derecha y seleccione el elemento de menú "Permission Policies" en el menú desplegable.

En la sección Permission Policies, puede gestionar todas las políticas. Por defecto, existe una super-admin-permission-policy para el administrador inicial.

Haga clic en el botón "Add Policy" en la esquina superior derecha para ingresar al formulario de creación de políticas. Aquí, debe completar la información básica de las políticas y configurar los permisos en el Editor de Políticas, denominados Statements.

Los Statements son los componentes centrales de una política, compuestos por una o más declaraciones. Cada declaración define una regla de acceso específica.

• Effect: Especifica el efecto de la declaración, generalmente "Allow" o "Deny". Un recurso puede verse afectado por múltiples políticas, y el sistema IAM determina los permisos de acceso finales basándose en el orden y la lógica de las declaraciones.

• Action: Define una serie de acciones permitidas o denegadas, como "gateway:DeleteGatewayGroup" o "iam:GetUser". Estas acciones deben usarse en conjunto con recursos (Resource) para ser significativas.

• Resource: Especifica los recursos a los que se aplica la declaración, como un grupo de gateways específico o un servicio. Se pueden usar comodines (por ejemplo, <.*>) para coincidir con múltiples recursos.

• Condition (opcional): Define las condiciones bajo las cuales la declaración será efectiva. Por ejemplo,

  "conditions": {
        "gateway_group_label": {
          "type": "MatchLabel",
          "options": {
            "key": "type",
            "operator": "exact_match",
            "value": "production"
          }
        }
      },
  

  Esto representa que las operaciones definidas en la declaración se permiten solo cuando la etiqueta del grupo de gateways está configurada como "production".

Por ejemplo, para crear una política que restrinja a un usuario a editar solo todos los servicios publicados dentro de un grupo de gateways específico, puede escribirlo de la siguiente manera:

{
  "statement": [
    {
      "resources": [
        "arn:api7:gateway:gatewaygroup/{gateway group id}"
      ],
      "actions": [
        "<.*>Get<.*>" // Permitir ejecutar todas las operaciones que comienzan con 'Get', que representan el permiso de 'lectura' para el grupo de gateways especificado
      ],
      "effect": "allow" // Permitir ejecutar las operaciones definidas anteriormente
      // Nota: Esta declaración de política permite realizar todas las operaciones 'Get' en el grupo de gateways especificado, como recuperar información del grupo de gateways, listar servicios dentro del grupo de gateways, etc.
    },
    {
      "resources": [
        "arn:api7:gateway:gatewaygroup/{gateway group id}/publishedservice/<.*>",
      ],
      "actions": [
        "<.*>" // Permitir ejecutar todas las operaciones
      ],
      "effect": "allow" // Permitir ejecutar las operaciones definidas anteriormente
      // Esta declaración de política permite realizar todas las operaciones (crear, leer, actualizar, eliminar, etc.) en los servicios publicados dentro del grupo de gateways especificado.
    }
  ]
}

En este ejemplo, definimos dos conjuntos de recursos (grupo de gateways y servicios publicados dentro del grupo de gateways) y establecimos las acciones permitidas para cada uno. Algunos ejemplos comunes de configuración de políticas se pueden encontrar en el documento Ejemplos de Políticas de Permisos. Para los valores disponibles de recursos y acciones y las API correspondientes, consulte el documento Acciones y Recursos de Políticas de Permisos.

Después de crear una política, no se puede asignar directamente a los usuarios; primero debemos asignar la política a roles específicos.

2. Crear Roles y Asignar Políticas

Después de iniciar sesión en API7 Enterprise, haga clic en el botón "Organization" en la esquina superior derecha y seleccione el elemento de menú "Roles" en el menú desplegable.

En la sección Roles, puede gestionar todos los roles. Por defecto, existe un rol de Super Admin como el rol de administrador integrado.

Haga clic en el botón "Add Custom Role" en la esquina superior derecha para ingresar al formulario de creación de roles. Aquí, debe completar la información básica del rol. Después de la creación, ingresaremos a la página de detalles del rol.

En la página de detalles del rol, haga clic en el botón "Attach Policy" para asignar las políticas de permisos creadas anteriormente al rol.

Las políticas creadas pueden reutilizarse en múltiples roles. Cuando un rol está asociado con múltiples políticas, estas políticas se combinan por defecto. Es decir, los permisos de un rol son la suma de los permisos declarados en todas las políticas asociadas. Después de crear un rol y asignar políticas, podemos asignar el rol a usuarios específicos.

3. Asignar Roles a Usuarios

Después de iniciar sesión en API7 Enterprise, haga clic en el botón "Organization" en la esquina superior derecha y seleccione el elemento de menú "Users" en el menú desplegable.

En la sección Users, puede gestionar todos los usuarios. Por defecto, existe un rol de administrador como el administrador integrado.

En la columna de acciones del lado derecho de la lista de roles, haga clic en "Update Roles" para abrir el cajón de formulario para actualizar el rol de un usuario específico.

Un usuario puede tener múltiples roles. Cuando se otorgan múltiples roles a un usuario, los permisos se combinan. Es decir, el usuario tiene la suma de los permisos de todos los roles.

Mapeo Simplificado de Roles

Con la optimización y actualización del modelo de roles de usuario, el proceso de mapeo de roles de SSO se ha simplificado. Ahora, al configurar el mapeo de roles para las opciones de inicio de sesión, no es necesario establecer reglas de coincidencia a nivel de recurso para cada rol individualmente. Los permisos de recursos y operaciones se heredan directamente de los roles integrados seleccionados, lo que hace que la configuración de permisos sea más intuitiva y simplifica la complejidad de la gestión de permisos.

Resumen

La introducción de políticas IAM ha permitido una configuración y gestión de permisos más flexible. Este ajuste no solo mejora la seguridad del sistema, sino que también proporciona a los usuarios una mayor posibilidad de personalización.

En el futuro, continuaremos ampliando los tipos de recursos compatibles con las políticas IAM, asegurando que todos los recursos del sistema puedan incluirse en la gestión granular de permisos, y optimizando continuamente la interfaz de edición y gestión de políticas, brindando a los usuarios una experiencia de gestión de permisos más completa y eficiente.