ENS desde dentro (XVIII): Mecanismo de autenticación (op.acc.6) — cómo demostrar que quien accede es quien dice ser

Ya sabes cómo se gestionan los accesos: quién los autoriza, quién los revisa y por qué. Pero falta la pieza que lo sostiene todo: ¿cómo compruebas que quien entra es realmente quien dice ser? Aquí entra op.acc.6.

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-gestion-accesos-op-acc-4/

Qué pide realmente el ENS

La autenticación se apoya en dos tipos de factores: algo que sabes (una contraseña) y algo que tienes (un certificado, un token, una app de verificación). Pueden usarse por separado o combinados, y combinarlos es lo que da lugar a la autenticación fuerte. El ENS distingue además entre usuarios de la organización y usuarios externos: son dos poblaciones distintas y, en auditoría, se piden evidencias separadas para cada una.

🧭 Paso 1: Política de contraseñas robusta

Longitud mínima, complejidad y caducidad no son una recomendación genérica: deben estar configuradas y ser demostrables. La evidencia típica es una captura de la política de contraseñas aplicada en el directorio activo, no una descripción en un documento.

🧭 Paso 2: Umbral de bloqueo de cuenta

Tras un número limitado de intentos fallidos, la cuenta debe bloquearse. Es habitual encontrar este umbral mal calibrado, permitiendo más intentos de los que define el procedimiento interno de control de acceso. Cuando eso pasa, es una no conformidad sencilla de detectar y de corregir: se ajusta la configuración, se verifica con una nueva captura y se documenta el cambio.

🧭 Paso 3: Segundo factor de autenticación (2FA)

Para los accesos más sensibles, la contraseña sola no basta. La evidencia aquí es visual: una captura del inicio de sesión mostrando el segundo factor en acción.

🧭 Paso 4: Accesos remotos

Todo acceso desde fuera de la red corporativa debe pasar por un canal controlado, normalmente una VPN. Se evidencia con una captura de la conexión establecida, no con una política que diga que se debe usar VPN.

🧭 Paso 5: Aviso y registro de accesos

El usuario debe poder ver cuándo fue su última conexión, y el sistema debe registrar tanto los intentos exitosos como los fallidos. Sin ese registro, no hay forma de reconstruir qué pasó ante un incidente.

🧭 Paso 6: Revisión periódica

Configurar bien una GPO una vez no es suficiente si nadie vuelve a mirarla. Lo que marca la diferencia es un control periódico, por ejemplo trimestral, que revise longitud mínima, complejidad, umbral y duración del bloqueo, con evidencia de que esa revisión se ha hecho y de que se ha comunicado al personal técnico responsable.

🧭 Paso 7: Ciclo de vida de la credencial

Dos cosas suelen pasarse por alto: que las credenciales inactivas durante un periodo definido se suspendan automáticamente, y que en operaciones sensibles el sistema exija renovar la autenticación aunque la sesión siga activa.

🧪 Evidencias que sí valen

Esto es lo que te van a pedir.

Buenas evidencias:

• Acuse de recibo firmado por el usuario al entregarle sus credenciales, aceptando la política de seguridad y sus obligaciones
• Captura de la política de contraseñas aplicada en el directorio activo
• Captura del aviso de obligaciones de seguridad mostrado al usuario
• Captura de un inicio de sesión con 2FA
• Captura de una conexión VPN establecida
• Captura del aviso de última conexión
• Registro de accesos con intentos exitosos y fallidos
• Captura del límite de intentos de autenticación configurado
• Evidencia de renovación de autenticación en operaciones sensibles
• Evidencia de credenciales suspendidas tras inactividad

Malas evidencias:

• Confiar en que los usuarios eligen buenas contraseñas
• Una política en un documento que nadie ha verificado que esté aplicada
• Sin registro de intentos fallidos
• Sin diferenciar usuarios internos de externos

Si no sale del sistema, no vale.

🧠 Ejemplo real

En una auditoría se detecta que el umbral de bloqueo de cuenta configurado en la GPO permite más intentos fallidos de los que define el procedimiento interno de control de acceso. Se abre una acción correctiva: se ajusta la configuración, se verifica con una nueva captura que el umbral queda alineado con el procedimiento, y se implanta una revisión trimestral para que no vuelva a desviarse. Resultado: no conformidad cerrada con evidencia documental completa.

Error típico (muy común)

Configurar bien una vez y no volver a revisarlo, no diferenciar autenticación de usuarios internos y externos, no registrar los intentos fallidos, y no dejar constancia de que el personal técnico ha sido informado de sus responsabilidades.

Lo que te van a pedir en auditoría

Las políticas de contraseñas aplicadas, la configuración de bloqueo de cuenta, evidencia de 2FA y VPN, el registro de accesos, la revisión periódica y el acuse de recibo de credenciales. Y la pregunta clave: ¿puedes demostrar que quien accedió era quien decía ser?

Conclusión

La autenticación no es un formulario de login: es la base sobre la que se sostiene todo lo demás — identificación, accesos, segregación. Si falla aquí, falla todo lo anterior.

Con esto cerramos el bloque op.acc

Hemos recorrido todo el control de acceso: identificación, requisitos de acceso, segregación de funciones, gestión de accesos y autenticación. Es el bloque más denso de la serie, y también el que más piden en auditoría.

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