Visión general del AMF

Editar en línea

La autenticación multifactor (AMF) amplía la autenticación de contraseñas para incluir un factor de autenticación adicional utilizado para verificar su identidad.

La solución MFA integrada IBM i solución MFA integrada incorpora una clave de contraseña de un solo uso basada en el tiempo (TOTP) que se almacena en el perfil del usuario y está protegida arquitectónicamente de forma similar a la contraseña. La clave TOTP se utiliza, junto con la hora del sistema, para generar un valor TOTP. El valor TOTP se presenta como un factor adicional a la hora de autenticarse. La implementación de IBM i la implementación se basa en el RFC 6238 -TOTP: Time-Based One-Time Password Algorithm (Algoritmo de contraseña de un solo uso basado en el tiempo)

La implementación de IBM i implementación sigue el RFC 6238, por lo que cualquier aplicación cliente compatible, como una aplicación de PC, una aplicación de teléfono inteligente, una aplicación de reloj inteligente o un token físico que cumpla con los estándares puede utilizarse para generar un valor TOTP. El perfil de usuario y la aplicación cliente compatible deben tener la misma clave TOTP o secreto compartido. La aplicación cliente, una vez configurada con la clave TOTP, genera valores TOTP basados en la clave TOTP y la hora actual del dispositivo. El usuario introduce el valor TOTP como factor de inicio de sesión adicional al autenticarse en el sistema. El sistema operativo valida el ID de usuario, la contraseña y el valor TOTP al mismo tiempo, lo que lo convierte en una autenticación multifactor.

Activación de la AMF

La solución MFA integrada en el sistema operativo IBM i solución MFA integrada en el sistema operativo requiere que el sistema tenga un nivel de seguridad (valor del sistema QSECURITY) 40 o superior y un nivel de contraseña (valor del sistema QPWDLVL) 4 o superior.

MFA está activado en su sistema cuando el atributo de seguridad Factor de inicio de sesión adicional está activado. Cuando se activa el factor de inicio de sesión adicional, algunas interfaces mostrarán un campo Factor adicional en la solicitud de inicio de sesión junto con los campos Usuario y Contraseña. Esto no significa que los usuarios deban introducir un factor adicional. El factor adicional sólo es necesario si el perfil del usuario se modifica para requerirlo, de lo contrario el factor adicional será ignorado. Habilitar el factor adicional para un perfil de usuario requiere acciones tanto del usuario como del administrador. La frecuencia con la que un usuario tiene que introducir un valor TOTP es configurable.

Las interfaces que no tienen un campo de factor adicional requieren que el valor del factor adicional se añada a la contraseña utilizando dos puntos como separador (contraseña:factor_adicional). El administrador del sistema debe instruir a los usuarios sobre cómo utilizar el campo de contraseña en las interfaces que no proporcionan un campo de factor adicional.

Para obtener más información, consulte Atributo de seguridad del factor de inicio de sesión adicional.

Cuando se pide a un usuario que introduzca un valor TOTP, es necesario que la hora del sistema y la hora de la aplicación autenticadora del cliente estén sincronizadas con unos pocos segundos de diferencia. El cliente Network Time Protocol (NTP) puede utilizarse para mantener la hora del sistema sincronizada con otros dispositivos de la red. Para más información, consulte Sincronización horaria mediante el Protocolo de tiempo de red (NTP ).

Los administradores de seguridad deben tener en cuenta el uso de contraseñas de aplicaciones cliente a la hora de habilitar los requisitos MFA para cada usuario. Los ejemplos de uso de contraseñas más difíciles son:
  • Contraseña en caché
    • La aplicación cliente almacena la contraseña de un usuario y se autentica en el servidor varias veces, a través de varias conexiones, durante un periodo de tiempo variable. El requisito de TOTP sensible al tiempo rompe la autenticación para estas aplicaciones. Las aplicaciones que piden permiso para almacenar la contraseña pueden identificarse, mientras que las que lo hacen de forma implícita deben descubrirse mediante pruebas.
    • Las aplicaciones pueden rediseñarse para solicitar credenciales en cada autenticación o para eliminar conexiones/autenticaciones adicionales.
    • Los administradores de seguridad pueden permitir que las aplicaciones de almacenamiento en caché de contraseñas funcionen para perfiles de usuario individuales configurando la frecuencia con la que se requiere un valor TOTP.
  • Elusión de contraseñas
    • La implementación del servidor de una aplicación omite la necesidad de la contraseña del perfil de usuario. Esto ocurre cuando el perfil de aplicación tiene autoridad sobre el perfil de usuario utilizado en una interfaz que permite un valor especial para la contraseña. Una aplicación puede realizar la autenticación independientemente del perfil de usuario y/o contraseña (como Kerberos ). Asociar un perfil de usuario con este tipo de autenticación que no requería contraseña, entra en conflicto con los requisitos de MFA.
    • Los administradores de seguridad pueden utilizar el identificador de función QIBM_RUN_UNDER_USER_NO_AUTH para controlar si se permite esta elusión.

Servidor de conexión host

El servidor de conexión host (HCS) permite a un cliente establecer sesiones autenticadas con varios servidores host. HCS permite a un cliente autenticarse una vez y luego utilizar esa sesión autenticada para transferir nuevas conexiones a otros servidores host sin tener que volver a autenticarse. Un usuario configurado para requerir siempre un valor TOTP sólo tiene que proporcionarlo una vez, eliminando la necesidad de solicitar credenciales varias veces. IBM i Access Client Solutions (ACS), IBM Navigator para i, y Digital Certificate Manager (DCM) han cambiado para utilizar HCS. Para más información, consulte Servidor de conexión host.

ID de la función QIBM_RUN_UNDER_USER_NO_AUTH

Debería considerarse la posibilidad de ejecutar acciones como otro perfil de usuario basándose únicamente en tener autoridad para ese perfil de usuario. Para conseguir una solución MFA completa, se recomienda que los perfiles de usuario requieran un valor TOTP y que también tengan restringido el acceso a este ID de función. El sitio IBM i implementación integrada de MFA TOTP permite esta elusión de contraseña debido al uso generalizado existente. Sin embargo, el identificador de función Ejecutar bajo un usuario sin autenticación (QIBM_RUN_UNDER_USER_NO_AUTH) debe utilizarse para bloquear las aplicaciones que evitan la necesidad de suministrar las credenciales del perfil de usuario. La auditoría de seguridad puede utilizarse para ayudar a determinar si las acciones fallarían si a un usuario se le deniega el acceso al identificador de función. Para más información, consulte el ID de uso de la función QIBM_RUN_UNDER_USER_NO_AUTH.
Nota: El ID de función QIBM_RUN_UNDER_USER_NO_AUTH no requiere que MFA esté habilitado o se utilice en el sistema.

IBM -perfiles de usuario suministrados

En IBM® hay perfiles de usuario con nombres que terminan en _NC, por "no modificable". Estos perfiles de usuario son los mismos que los perfiles de usuario correspondientes con nombres que no terminan en _NC, sin embargo no se pueden modificar y no tienen contraseña. A estos perfiles de usuario tampoco se les puede denegar el acceso a la función QIBM_RUN_UNDER_USER_NO_AUTH ID. Se utilizan en lugares en los que antes se utilizaban perfiles de usuario distintos de _NC, como al enviar trabajos, obtener manejadores de perfil o como perfil de usuario bajo el que se ejecuta un servidor. También deben ser utilizados por las aplicaciones en caso de que al perfil de usuario no _NC se le deniegue el acceso a la función QIBM_RUN_UNDER_USER_NO_AUTH ID.
  • QPGMR_NC
  • QSECOFR_NC
  • QSYSOPR_NC
  • QUSER_NC

Fichas de perfil mejoradas

La protección de seguridad mejorada está disponible con fichas de perfil. Cuando se genera un token de perfil, puede especificar un ID de verificación y/o una dirección IP remota cambiando la aplicación para especificar estos parámetros. El ID de verificación y/o el puerto remoto correspondientes también deben especificarse en la solicitud de configuración para que tenga éxito. Esto garantiza que el token de perfil no está siendo utilizado por un actor malintencionado. Para más información, consulte Protección de seguridad de token de perfil mejorada.
Nota: El token de perfil mejorado no requiere que MFA esté habilitado o se utilice en el sistema.

Punto de salida de autenticación única QIBM_QSY_AUTH

Las soluciones de seguridad de los proveedores de software independientes (ISV) suelen depender de los puntos de salida de IBM para aplicar protecciones de seguridad adicionales a las que proporciona el sistema operativo. El punto de salida QIBM_QSY_AUTH proporciona una forma de llamar a un programa de salida durante el proceso de autenticación para todas las aplicaciones que realizan una operación aplicable. El programa de salida registrado en la facilidad de registración, bajo el punto de salida QIBM_QSY_AUTH, es llamado cuando un perfil de usuario es cambiado para requerir llamar al programa de salida. Al programa de salida se le pasa información para que la utilice para realizar verificaciones adicionales y puede devolver indicadores de éxito o fracaso. Alguna información pasada al programa de salida estará en blanco si la aplicación no la proporciona en las llamadas a las interfaces de autenticación. A un usuario con privilegios elevados se le podría requerir que proporcione una contraseña y un valor TOTP, y que se llame al programa de salida. El programa de salida podría generar una notificación push fuera de banda a un teléfono que requiera una huella dactilar para continuar. Para más información, consulte *Método de autenticación REGFAC.
Nota: El punto de salida de autenticación QIBM_QSY_AUTH no requiere que MFA esté habilitado o se utilice en el sistema.

Consideraciones para los desarrolladores de aplicaciones

Algunas interfaces de autenticación de sistemas con un parámetro de contraseña de usuario tienen un parámetro de factor de autenticación adicional separado. La experiencia del usuario puede mejorar cuando las aplicaciones exponen a sus usuarios una solicitud de autenticación adicional. Esto se puede conseguir si la aplicación determina que el atributo de seguridad Factor de inicio de sesión adicional está activado y, a continuación, utiliza el parámetro Factor de autenticación adicional en las interfaces de autenticación. Las interfaces de autenticación IBM i interfaces de autenticación también incluyen parámetros para proporcionar la información adicional requerida para ser pasada al programa de salida QIBM_QSY_AUTH o para crear un token de perfil mejorado. El programa de salida QIBM_QSY_AUTH puede analizar más información cuando las aplicaciones proporcionan consistentemente la información adicional en las llamadas de interfaz aplicables. Sin embargo, la solución IBM i solución AMF integrada es funcional sin cambios en la aplicación para utilizar estos parámetros. Para obtener más información sobre las interfaces con los parámetros correspondientes, consulte *Método de autenticación ERGFAC y Protección de seguridad mediante token de perfil mejorada.

Herramientas de servicio

Las herramientas de servicio del sistema (SST) y las herramientas de servicio dedicadas (DST) soportan una implementación de clave TOTP MFA independiente no conectada al soporte MFA del sistema operativo. Las claves TOTP establecidas para los usuarios de TSM no tienen relación con las claves TOTP establecidas para los perfiles de usuario IBM i perfiles de usuario, concretamente un usuario TSM con un perfil vinculado no comparte una clave TOTP con el perfil vinculado. Otra diferencia es que SST no permite establecer una frecuencia para proporcionar el valor TOTP, se requiere cada vez que se necesita una contraseña. Un administrador de SST puede habilitar MFA para SST sin habilitarlo en el sistema operativo. Para más información, consulte Herramientas de servicio Autenticación multifactor (MFA).