Revisiones de acceso y segregación de funciones
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 5 → 6
ActualizaciónReescrito con la documentación del producto. Estas funciones pertenecen a Monosign, así que el curso pasó allí. Se eliminaron la revocación automática, los informes por marco normativo y los antiguos nombres de aplicación; en su lugar se enseñan la corrección manual y las carencias conocidas de la segregación de funciones.
1 lección actualizada
Actualización de contenido. Se notificó a los estudiantes inscritos.
La **segregación de funciones (SoD)** impide que una persona tenga una combinación de derechos que le permita cometer y ocultar un error o un fraude, como crear un proveedor y aprobar su pago.
### Dónde están las reglas
Las reglas son **triggers** que se crean en **Workflows → Triggers → Add New** en Monosign. Ponga **Category** en **Segregation of Duties**, describa la combinación tóxica en **Rules** con condiciones como `User.Permission`, `User.Role` o `User.Group`, y limite cuándo se aplica en **Scope**. Ya no se puede llegar a la antigua pantalla **Security → Segregation of D.**.
::diagram sar-sod-enforce-detect
### Aplicación y detección van por separado
La **Decision** aplica la regla en el momento del cambio:
- **Allow** ejecuta las acciones.
- **Block (Veto)** rechaza el evento.
- **Require approval** lo envía a un aprobador, cuya cola es la pestaña **Approvals** de **Triggers**.
- **Allow & notify** lo permite, pero avisa y exige una justificación.
Si coinciden varias reglas, gana el resultado más restrictivo. Si la evaluación da error, el resultado es denegar.
**Category** selecciona la regla para el **análisis de detección**, que busca a quienes ya tienen la combinación. Los resultados aparecen en **Identity → Visibility** como el indicador **SoD violations** y la etiqueta SoD. Definir uno no define el otro, así que configure ambos.
> Consejo: Las aprobaciones de paquetes de acceso no pasan por los triggers de SoD, así que una regla Block (Veto) no detiene una combinación concedida mediante un paquete de acceso. Incluya también los paquetes de acceso en su diseño de SoD: revise qué concede cada paquete y compruebe los titulares con el análisis de detección. El análisis cubre como máximo 3000 titulares por trigger.
### Qué hacer al respecto
- El análisis se ejecuta cada vez que se reconstruye el grafo de Identity Visibility. Compruebe sus resultados con regularidad y divida el ámbito del trigger si una regla tiene miles de titulares.
- Revise a mano las definiciones de paquetes de acceso en busca de combinaciones tóxicas.
- Si un conflicto debe quedarse por motivos de negocio, documente un control compensatorio, como que un supervisor revise la actividad.
> Consejo: Empiece por unas pocas combinaciones que sus auditores ya preguntan, no por una gran matriz que nadie mantiene.