ENS desde dentro (XV): Requisitos de acceso (op.acc.2) — quién puede hacer qué

Controlar quién accede no es suficiente: hay que justificarlo. Aprende cómo gestionar permisos, usar grupos y demostrar accesos en auditoría ENS (op.acc.2).

Share
ENS desde dentro (XV): requisitos de acceso en el sistema, representados con checklist, Active Directory y candado sobre fondo tecnológico azul.
Requisitos de acceso en el ENS (op.acc.2): permisos justificados, gestionados y trazables para garantizar control real sobre quién accede a qué.

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-identificacion-op-acc-1


Introducción

Ya sabes quién es cada usuario y que cada identidad es única. Pero falta lo importante: qué puede hacer cada uno. Aquí entra op.acc.2.

Qué pide realmente el ENS

Es muy claro: nadie accede sin permiso, cada acceso debe estar autorizado y cada permiso debe estar justificado. Acceso sin control es riesgo.

🧭 Paso 1: Controlar el acceso a los recursos

Todo recurso debe estar protegido: sistemas, aplicaciones, ficheros y configuraciones. Solo deben acceder los usuarios con permisos concedidos.

Ejemplo real:

  • Carpeta compartida → acceso restringido
  • Aplicación → login obligatorio
  • Servidor → acceso limitado

🧭 Paso 2: Asignar permisos correctamente

Los permisos no se asignan porque sí: deben estar autorizados, documentados y responder a una necesidad real. Nadie debería tener más acceso del que necesita para hacer su trabajo.

Por ejemplo:

  • Usuario → lectura
  • Técnico → modificación
  • Admin → control total

🧭 Paso 3: Gestión por grupos (clave en auditoría)

En auditoría se espera ver permisos gestionados por grupos de Active Directory, no asignados usuario por usuario. Por ejemplo, un grupo como GG_APP_FINANZAS_LECTURA agrupa a quienes solo consultan, y GG_APP_FINANZAS_ADMIN a quienes administran.

Esto da tres ventajas: control centralizado, auditoría más fácil y escalabilidad cuando crece el equipo. Asignar permisos directamente a un usuario, sin pasar por un grupo, es una mala práctica que un auditor detecta enseguida.

🧭 Paso 4: Permisos individuales (cuando aplica)

No todo se resuelve por grupos. A veces hacen falta permisos específicos o excepciones controladas, pero esas excepciones también deben estar justificadas y documentadas, no ser una vía para saltarse el proceso.

🧭 Paso 5: Evidencia de autorización

Esto es crítico: todo acceso debe tener una solicitud, una aprobación y una implementación registradas. En la práctica esto se traduce en un ticket de acceso, la aprobación del responsable correspondiente y la ejecución por parte de IT. Si no hay ticket, para el auditor ese acceso no existe.

🧪 Evidencias que sí valen

Esto es lo que un auditor considera evidencia válida, y lo que no.

Buenas evidencias:

  • Ticket de solicitud de acceso
  • Aprobación del responsable
  • Captura de los grupos en Active Directory
  • Listado de permisos por usuario
  • Evidencias de la asignación

Malas evidencias:

  • "Se le dio acceso" (sin más)
  • Correo sin trazabilidad
  • Permiso sin justificar

Si no puedes seguir el rastro completo de un acceso, esa evidencia no vale.

🧠 Ejemplo real

El auditor revisa los permisos de un usuario concreto y detecta acceso a sistemas que no usa, permisos excesivos para su función, y ninguna evidencia de aprobación. El resultado: no conforme.

Error típico (muy común)

Los errores más comunes que veo en auditoría son: permisos por defecto que nadie revisa, usuarios metidos en demasiados grupos, accesos sin justificar, y no usar grupos en absoluto. El resultado es siempre el mismo: exceso de privilegios, riesgo de seguridad y fallo en auditoría.

Lo que te van a pedir en auditoría

En auditoría te van a pedir: quién tiene acceso a qué, cómo se ha autorizado, cómo se gestiona y si está justificado. Y la pregunta clave que resume todo: ¿puedes demostrar por qué alguien tiene ese acceso?

Conclusión

Identificar no es suficiente: hay que controlar los permisos. El acceso debe estar autorizado, limitado y justificado. Si lo haces bien, tienes control real. Si lo haces mal, tienes riesgo.

Próximo paso

Seguimos avanzando. En el siguiente artículo, op.acc.3 – Segregación de funciones, veremos separación de roles, conflictos de interés y errores reales.

👉 Accede a la guía completa del ENS: https://www.handersonboratto.com/ens-desde-dentro/