ENS desde dentro (XV): Requisitos de acceso (op.acc.2) — quién puede hacer 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
👉 que cada identidad es única

Pero falta lo importante:

💣 qué puede hacer cada uno

👉 Aquí entra op.acc.2

Qué pide realmente el ENS

Muy claro:

👉 nadie accede sin permiso
👉 cada acceso debe estar autorizado
👉 cada permiso debe estar justificado

💣 Acceso sin control = riesgo

🧭 Paso 1: Controlar el acceso a los recursos

Todo recurso debe estar protegido:

• sistemas
• aplicaciones
• ficheros
• configuraciones

👉 Solo acceden:

💣 usuarios con permisos

👉 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
• estar documentados
• responder a una necesidad

💣 Nadie debería tener más de lo necesario

👉 Ejemplo:

• usuario → lectura
• técnico → modificación
• admin → control total

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

Esto es lo que se espera ver:

👉 Uso de grupos en Active Directory

• GG_APP_FINANZAS_LECTURA
• GG_APP_FINANZAS_ADMIN

👉 Ventaja:

• control centralizado
• fácil auditoría
• escalable

💣 Usuario directo en permisos = mala práctica

🧭 Paso 4: Permisos individuales (cuando aplica)

No todo es por grupos.

👉 A veces necesitas:

• permisos específicos
• excepciones controladas

👉 Pero:

💣 deben estar justificadas

🧭 Paso 5: Evidencia de autorización

Esto es crítico.

👉 Todo acceso debe tener:

• solicitud
• aprobación
• implementación

👉 Ejemplo real:

• ticket de acceso
• aprobación del responsable
• ejecución por IT

💣 Sin ticket = no existe

🧪 Evidencias que sí valen

Esto es lo que te van a pedir:

✔ Buenas evidencias

• ticket de solicitud de acceso
• aprobación del responsable
• captura de grupos en AD
• listado de permisos por usuario
• evidencias de asignación

❌ Malas evidencias

• “se le dio acceso”
• correo sin trazabilidad
• permiso sin justificar

💣 Si no puedes seguir el rastro, no vale

🧠 Ejemplo real

El auditor revisa:

👉 permisos de un usuario

Detecta:

• acceso a sistemas que no usa
• permisos excesivos
• sin evidencia de aprobación

💣 Resultado:

❌ no conforme

Error típico (muy común)

❌ permisos por defecto sin revisar
❌ usuarios en demasiados grupos
❌ accesos sin justificar
❌ no usar grupos

💣 Resultado:

👉 exceso de privilegios
👉 riesgo de seguridad
👉 fallo en auditoría

Lo que te van a pedir en auditoría

👉 quién tiene acceso a qué
👉 cómo se ha autorizado
👉 cómo se gestiona
👉 si está justificado

👉 Y la pregunta clave:

💣 ¿puedes demostrar por qué alguien tiene acceso?

Conclusión

Identificar no es suficiente.

👉 Hay que controlar permisos

💣 El acceso debe estar:

• autorizado
• limitado
• 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
• errores reales

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