ENS desde dentro (XVI): Segregación de funciones (op.acc.3) — que nadie tenga todo el control
La segregación de funciones evita que una sola persona tenga control total. Aprende cómo separar roles, limitar privilegios y demostrarlo en auditoría ENS (op.acc.3).
Ya sabes quién es cada usuario y qué permisos tiene. Pero hay un problema: ¿y si alguien puede hacerlo todo? Aquí entra op.acc.3.
Este artículo forma parte de la serie ENS desde dentro.
👉 Puedes ver la guía completa aquí:
https://www.handersonboratto.com/ens-desde-dentro/
👉 Si es tu primera vez en la serie, empieza por aquí:
https://www.handersonboratto.com/blog/que-es-ens/
👉 O continúa con el artículo anterior:
https://www.handersonboratto.com/blog/ens-requisitos-acceso-op-acc-2/
Qué pide realmente el ENS
Es muy claro: separar funciones, evitar conflictos y limitar el poder de una sola persona. Nadie debería tener control total.
🧭 Paso 1: Separar roles críticos
Esto es la base. Un ejemplo claro: desarrollo, sistemas y producción no deben mezclarse. El caso típico es un desarrollador con acceso a producción — resultado: riesgo alto y no conformidad.
🧭 Paso 2: Separar quien autoriza y quien ejecuta
Esto es clave en auditoría. No debe pasar que el mismo usuario solicite el acceso y lo apruebe: eso rompe el control. Lo correcto es que el usuario solicite, el responsable apruebe e IT ejecute.
🧭 Paso 3: Limitar privilegios críticos
Hay funciones sensibles — configuración, administración, seguridad — que deben estar separadas. Por ejemplo: el administrador de sistemas no debe ser el auditor, y el operador no debe ser el supervisor.
🧭 Paso 4: Control en aplicaciones
Esto se ve muy claro en auditoría. Un ejemplo real: un usuario entra en la aplicación y no ve opciones de configuración — eso es correcto. Lo contrario, un usuario normal con opciones de administrador, es no conforme.
🧭 Paso 5: Separación en Active Directory
Es muy típico en entornos reales: desarrolladores fuera de los grupos de producción, administradores en grupos controlados y usuarios sin privilegios elevados. Si mezclas los grupos, pierdes el control.
🧪 Evidencias que sí valen
Esto es lo que te van a pedir.
Buenas evidencias:
- Captura de usuario sin acceso a configuración
- Grupos en AD separados (dev / prod / admin)
- Roles definidos en aplicaciones
- Separación de funciones documentada y aplicada
Malas evidencias:
- “Cada uno sabe lo que hace”
- Roles no definidos
- Permisos mezclados
- Acceso excesivo
Si no está limitado, no vale.
🧠 Ejemplo real
El auditor revisa los accesos a producción y detecta desarrolladores con acceso directo, sin control y sin separación. Resultado: no conforme.
Error típico (muy común)
Desarrolladores en producción, administradores con todos los roles, usuarios con acceso a configuración y auditores con permisos operativos. Resultado: riesgo elevado, pérdida de control y fallo en auditoría.
Lo que te van a pedir en auditoría
La separación de roles, las evidencias de restricción, el control de privilegios y la ausencia de conflictos. Y la pregunta clave: ¿puede una sola persona hacerlo todo?
Conclusión
El problema no es el acceso: es el exceso de poder. La segregación reduce el riesgo. Si lo haces bien, tienes control real. Si lo haces mal, tienes un punto único de fallo.
Próximo paso
Seguimos avanzando. En el siguiente artículo: op.acc.4 – Gestión de derechos de acceso. Veremos altas, bajas, revisiones y evidencias reales.
👉 Accede a la guía completa del ENS:
https://www.handersonboratto.com/ens-desde-dentro/