Flujos de trabajo de aprobación en Oracle Access Governance
Los flujos de trabajo de aprobación son procesos estructurados diseñados para automatizar las aprobaciones en función de flujos de trabajo predefinidos. Estos flujos de trabajo garantizan que las solicitudes de acceso, las microcertificaciones y los exámenes de acceso sean revisados y aprobados por las partes interesadas pertinentes, lo que mejora la seguridad y el cumplimiento.
Por ejemplo, cuando un usuario solicita acceso a un grupo de acceso mediante un módulo de autoservicio, el flujo de trabajo de aprobación asociado a esa solicitud dispara una notificación por correo electrónico a los aprobadores, que luego revisan la solicitud y deciden aprobarla, rechazarla o solicitar más información. El resultado del proceso de aprobación se actualiza y las actividades de aprovisionamiento se activan en el sistema orquestado específico. Para crear y gestionar flujos de trabajo de aprobación, consulte Crear flujos de trabajo de aprobación y Gestionar flujo de trabajo de aprobación.
Plantillas de flujo de trabajo de aprobación incorporadas
Oracle Access Governance ofrece plantillas de flujo de trabajo de aprobación que puede utilizar como base para diseñar los flujos de trabajo personalizados. Puede combinar varias plantillas en paralelo o secuencialmente para crear sus propios flujos de trabajo de aprobación.
Beneficiario/Beneficiaria
La solicitud de aprobación se envía a la identidad que recibe el acceso (el beneficiario), lo que les permite autoaprobar un permiso específico. El usuario que solicita el acceso debe aprobarlo por sí mismo. Adecuado para permisos de bajo riesgo donde se confía en que el beneficiario apruebe su propio acceso
Ejemplo: utilícelo para solicitar acceso al software empresarial preaprobado y sin licencia, donde el beneficiario aprueba por sí mismo la solicitud.
Gestor del beneficiario
La solicitud de aprobación se envía al mánager del beneficiario. Utilice esta opción para validar si el acceso es adecuado, relevante o está dentro del ámbito empresarial.
Ejemplo: utilice esta opción al solicitar acceso a una herramienta de terceros con licencia.
Propietario Principal
La solicitud de aprobación se envía al responsable principal del recurso. Puede configurar para permitir o no la autoaprobación. Si la autoaprobación se define en Sí, el aprobador y el beneficiario pueden tener la misma identidad.
Ejemplo: envío de una solicitud de aprobación al propietario principal del grupo de acceso para aprobar los permisos relacionados con la base de datos dentro de un grupo de acceso.
Propietarios
La solicitud de aprobación se envía a los propietarios de recursos (propietarios principales y adicionales) para garantizar el uso correcto del recurso. Puede configurar para permitir o no la autoaprobación. Si la autoaprobación se define en Sí, el aprobador y el beneficiario pueden tener la misma identidad.
Ejemplo: envío de una solicitud de aprobación a los propietarios del grupo de acceso para aprobar solicitudes de acceso al grupo de acceso.
Usuario personalizado
La solicitud de aprobación se dirige a una identidad predefinida específica, normalmente para un control centralizado. Adecuado para escenarios que requieren autoridad de aprobación especializada.
Ejemplo: envío de una solicitud de aprobación a un administrador de TI cuando un contratista solicita acceso a una aplicación de colaboración de equipo empresarial.
Cadena de Gestión
La solicitud de aprobación sigue una estructura jerárquica, a partir del mánager del beneficiario y subiendo la cadena según sea necesario. Adecuado para permisos críticos para el negocio que requieren aprobaciones de varios niveles.
Ejemplo: utilice esta opción cuando una identidad solicite un permiso de rol "Contributors" para publicar y descargar actualizaciones en un sistema de almacenamiento orientado al cliente.
Recopilaciones de identidades
- Número mínimo de aprobaciones necesarias para continuar con la solicitud.
- Poder de veto para denegar la solicitud, si algún miembro lo rechaza.
- Recopilación de identidades escalada que recibe la solicitud al caducar la línea de tiempo de la solicitud original.
Si el grupo carece de suficientes miembros, la solicitud se cancela. Consulte Gestión de Grupos Grandes en Flujos de Trabajo de Aprobación.
Ejemplo: utilícelo cuando una identidad solicite un acceso de privilegio de administrador de base de datos para enrutar una solicitud a la recopilación de identidades de administrador de base de datos.Gestión de escalonamientos en flujos de trabajo de aprobación
Al configurar los flujos de trabajo de aprobación, puede definir una hora de escalada, es decir, el número de días que se debe esperar antes de escalar la solicitud de aprobación al siguiente aprobador. Esto sucede porque el aprobador original no respondió en el tiempo configurado.
Se aplica a: Beneficiario, mánager del beneficiario, Propietario, Usuario personalizado, tipos de plantilla de Cadena de gestión
La primera escalada se produce cuando una tarea de aprobación no se ha completado a tiempo. Busca en la cadena de gestión del aprobador original el primer mánager activo disponible. Las escaladas posteriores se producen si incluso el aprobador escalado no realiza ninguna acción. Ahora, el sistema inicia la siguiente búsqueda desde el mánager de la última persona que tuvo la tarea y continúa en la cadena.
Cada vez que el temporizador de escalada caduca para una solicitud, Oracle Access Governance sigue un proceso estructurado para avanzar en la tarea. Se envía un correo electrónico de notificación al aprobador escalado (gestor o parte de identidad de la recopilación de identidades escalada) para informarles sobre la tarea escalada.
- Primera escalada: busca en la cadena de gestión del aprobador el primer mánager activo incluido en Oracle Access Governance.
- Escaladas posteriores: busca al mánager del aprobador más reciente al que se escaló la tarea, lo que conitina la cadena de gestión.
- Consideración de límite máximo: si se define un límite máximo de escalada (número máximo de niveles de jerarquía), la búsqueda detiene un nivel antes de alcanzarlo.
- Busca cada parte de miembro de la recopilación de identidades escalada y asigna la tarea a cualquier persona que aún no la haya recibido. Si la tarea ya se ha escalado a todas ellas, no se realiza ninguna otra acción. Si se define un límite de escalada (número máximo de niveles de jerarquía), la búsqueda detiene un nivel antes de alcanzarlo.
Gestión de aprobaciones de grupos grandes: límite y criterios de miembros
Cuando selecciona una recopilación de identidades para cualquier parte del flujo de trabajo de aprobación, como aprobaciones, escaladas o delegaciones, Oracle Access Governance aplica un límite de miembros.
Puede seleccionar una recopilación de identidades de cualquier tamaño, pero solo un máximo de 25 miembros pueden recibir y aprobar tareas de forma activa. Oracle Access Governance selecciona los primeros 25 miembros ACTIVE/WORKFORCE.
ACTIVE/WORKFORCE disponibles, se agregan CONSUMERS para alcanzar el límite de 25 miembros. Sin embargo, ningún miembro CONSUMER recibe una tarea de aprobación; en su lugar, se activa un mecanismo de reserva, de la siguiente manera.- Para ver las revisiones de acceso, consulte Mecanismo de reserva en revisión de acceso.
- Para las solicitudes de acceso, Oracle Access Governance busca en la cadena de gestión del aprobador hasta que encuentra un
ACTIVE/WORKFORCE, que luego se asigna como aprobador.Nota
Para los flujos de trabajo de aprobación escalados o delegados, no se tienen en cuenta los miembros del consumidor y no se aplica el mecanismo de reserva.
Cambio de afiliación en asignación de aprobación
Las tareas de revisión siempre permanecen con los 25 miembros asignados. Si un miembro se elimina de una recopilación de identidades o se convierte en INACTIVE/CONSUMER, las tareas se transfieren a otro miembro del grupo para mantener el recuento de 25 miembros.
Matrices y criterios de aprobación automática
En las siguientes tablas se resumen los criterios clave para la aprobación automática en las dos matrices.
| ¿El aprobador es solicitante o el flujo de trabajo tiene un IC de aprobación automática y el solicitante es miembro? | El flujo de trabajo permite la aprobación automática si existen infracciones de AGR o SOD. | El flujo de trabajo permite la autoaprobación. | ¿Es el beneficiario del aprobador? | ¿Hay violaciones? | Acción de aprobación automática |
|---|---|---|---|---|---|
| Sí | No | No | No | No | Aprobar |
| Sí | No | No | No | Sí | No hay acciones |
| Sí | No | No | Sí | No | No hay acciones |
| Sí | No | No | Sí | Sí | No hay acciones |
| Sí | No | Sí | No | No | Aprobar |
| Sí | No | Sí | No | Sí | No hay acciones |
| Sí | No | Sí | Sí | No | Aprobar |
| El flujo de trabajo está configurado para aprobarse automáticamente si no se detectan infracciones de AGR o SOD. | ¿Hay violaciones? | Acción de aprobación automática |
|---|---|---|
| Sí | No | Aprobar |
| Sí | Sí | No hay acciones |