¿Buscas más granularidad en la administración de cómo configurar Identity Threat Protection con Okta AI? Entendemos que la seguridad es un esfuerzo de equipo y que los diferentes administradores tienen diferentes responsabilidades. Para alinear mejor el acceso con estas responsabilidades y adherirnos al principio del mínimo privilegio, Okta ha lanzado una nueva capacidad para extender los roles de administrador personalizados a nuevos permisos y tipos de recursos para Identity Threat Protection con Okta AI.
¿Qué es la Protección contra Amenazas de Identidad con Okta AI?
Identity Threat Protection with Okta AI es un producto que se ejecuta dentro de Okta Workforce Identity. Está sujeto al modelo administrativo con usuarios/grupos asignados a Admin Roles.
Anteriormente, ampliamos la función de roles de administrador para permitir la creación de Roles de administrador personalizados. Esto comprendió dos partes:
- Exponer los Role Permissions que estaban integrados en los roles de administrador estándar, de modo que se pudieran definir roles personalizados. Estos permisos describen las operaciones que se pueden realizar en los objetos, como “Administrar usuarios”, “Crear usuarios” y “Editar los estados del ciclo de vida de los usuarios”.
- Agregar Conjuntos de recursos con recursos permite que los roles de administrador se limiten a conjuntos de datos específicos. Por ejemplo, podrías tener un conjunto de recursos para todos los usuarios, sus grupos y aplicaciones en un departamento específico para restringir los roles de administrador solo a esos objetos.
Ahora hemos ampliado esta funcionalidad para incluir nuevos permisos para las operaciones relacionadas con Identity Threat Protection y nuevos recursos. Esta no es una nueva función, sino una expansión del conjunto de funciones existente con más permisos y tipos de recursos.
Roles y permisos
No agregamos nuevos roles, pero hay nuevos permisos disponibles, incluyendo la capacidad de:
- Ver y administrar el riesgo del usuario
- Ver y administrar flujos de receptor de Shared Signals Framework (SSF)
- Ver y administrar políticas
- Ver informes
- Configure el cierre de sesión
- Crear un flujo de trabajo
Al definir las funciones, es posible que desee considerar la inclusión de permisos para:
- Ver o modificar usuarios: Incluye acceso para ver o modificar usuarios
- Borrar las sesiones de los usuarios: Proporciona acceso de administrador para borrar las sesiones de los usuarios.
- Ver grupos: Requerido para que los administradores vean las asignaciones de grupos en la política de riesgo de entidad y la política de sesión posterior a la autenticación
- Administrar aplicaciones: Les da a los administradores la capacidad de configurar el Cierre de sesión universal para una aplicación
- Ejecutar flujo delegado: Permite la capacidad de ejecutar un flujo delegado para usar en la política de riesgo de la entidad o en la política de sesión posterior a la autenticación
- Ver flujo delegado: Permite la capacidad de ver un flujo delegado
- Administrar personalizaciones: Requerido para que los administradores administren la política de sesión posterior a la autenticación
Puede utilizar estos nuevos permisos para crear roles de administrador personalizados para Identity Threat Protection. Por ejemplo, puede extender la capacidad de ver y escalar el riesgo a sus administradores de usuarios, pero tener roles separados para administrar las políticas y las integraciones de SSF.
Para una comparación de los permisos de los roles para los diferentes roles de administrador, consulta la documentación del producto.
Conjuntos de recursos
Los conjuntos de recursos son colecciones de recursos asignados a roles de administrador para conceder acceso administrativo. Un rol define lo que un usuario puede hacer (operaciones), y un conjunto de recursos define sobre qué puede operar ese rol (datos).
Se han añadido dos nuevos tipos de recursos para esta función:
- Receptor del Shared Signals Framework (SSF)
- Políticas (por ejemplo, Política de riesgo de entidad, Política de protección de sesión)
Estos se pueden combinar con otros tipos de recursos (como usuarios, aplicaciones, grupos y flujos de trabajo) para admitir un modelo administrativo delegado.
Ejemplo de rol de administrador personalizado
Veamos una instancia de una función de administrador personalizada para un administrador de Identity Threat Protection que cubre todos los aspectos de Identity Threat Protection, pero no al nivel de una función de Okta Super Admin.
La función tiene los siguientes permisos:
- Usuario
- Desactivar usuarios
- Suspender usuarios
- Borrar las sesiones de los usuarios
- Gestionar el riesgo de los usuarios
- Grupo
- Ver un grupo y sus detalles
- aplicación
- Ver una aplicación y sus detalles
- flujo de trabajo
- Ver un flujo delegado
- Ejecutar un flujo delegado
- Receptor del marco de señales compartidas
- Administrar flujos de receptor de Shared Signals Framework (SSF)
- Políticas
- Administrar políticas
En este escenario, la función proporciona acceso limitado al usuario: la capacidad de ver (pero no modificar) las aplicaciones y los grupos del usuario y de ver el riesgo del usuario (pero no acceder al perfil o los dispositivos del usuario).
La extensión de los roles de administrador personalizados dentro de Identity Threat Protection permite un control más granular sobre los permisos de administrador. Al agregar nuevos permisos y tipos de recursos, las organizaciones pueden crear roles específicos adaptados a la administración de Identity Threat Protection sin depender únicamente de los privilegios de Superadministrador. Esta mejora aumenta la seguridad y reduce los riesgos al permitir la asignación precisa de responsabilidades administrativas, lo que en última instancia conduce a una implementación más segura de Okta.
Las funciones extendidas permiten borrar las sesiones de usuario, elevar el riesgo y suspender/desactivar al usuario.
Esta actualización también permite el acceso a grupos, aplicaciones, políticas de seguridad y algunas otras funciones comunes de administración, así como la capacidad de administrar los receptores SSF. Sin embargo, no permite la configuración de Universal Logout para una aplicación.
El rol de administrador puede entonces ser delimitado por recursos en un conjunto de recursos: Aplicaciones específicas, usuarios (por grupo), flujos de trabajo, políticas y grupos. Cuando se combina con los permisos nuevos (y existentes), puede definir administradores con los permisos apropiados y eliminar la necesidad del rol de Super Administrador, reduciendo así los riesgos de ese rol para su implementación de Okta.
¿Listo para aprender más? Consulta la documentación en nuestra base de conocimientos o explora las nuevas funciones de Identity Threat Protection con Okta AI en nuestra última entrada de blog.
