Segregación de funciones y doble aprobación

La segregación de funciones reparte las etapas de un cambio (escribirlo, revisarlo, aprobarlo, desplegarlo) entre personas distintas para que nadie pueda llevar a producción algo sin que otra persona lo haya visto. PCI DSS v4.0.1 lo expresa para entornos en el requisito 6.5.4: los roles y funciones se separan entre producción y preproducción para que solo se desplieguen cambios revisados y aprobados. La revisión de código del requisito 6.2.3 pide además que la hagan personas distintas del autor.

Una doble aprobación solo cumple su propósito si las dos aprobaciones son independientes del autor y entre sí.

Las plataformas de código suelen ofrecer una opción para que el autor pueda aprobar su propio cambio, pensada para equipos de una persona. En una rama de producción de pagos, esa opción anula la separación: el control se ve activo y no protege.

Lee la protección de la rama principal y busca la opción que lo permite.

Para medir el daño de una opción mal puesta se cruza el historial: en cada cambio, ¿el autor aparece entre sus aprobadores? La respuesta no se saca de una celda, se obtiene recorriendo todas las filas del mes y comparando el autor con las dos columnas de aprobadores.

Una cuenta de servicio no revisa código: aplica una regla. Si una cuenta automática figura como aprobadora, la segunda revisión humana desaparece aunque el contador marque dos. A veces nace de buena fe: alguien automatiza la aprobación de cambios «de bajo riesgo» para destrabar la cola y el automatismo termina aprobando de todo.

Cruza el historial con el directorio de cuentas.

Los equipos se saltan la aprobación por una razón legítima: a veces hay que corregir en producción de inmediato. La solución no es quitar el control sino diseñar una vía de emergencia: una cuenta o rol de uso excepcional, con alertas cuando se usa, y una revisión posterior obligatoria por una persona ajena al cambio, dentro de un plazo corto. Así la excepción queda a la vista y no se vuelve costumbre.