Configurar la autenticación multifactor¶
La autenticación multifactor (MFA) solicita al usuario una segunda prueba además de su identificador y su contraseña. CyberElements Bastion ofrece varias formas de obtenerla. Esta página cubre cuatro de ellas, en el orden en el que se plantean habitualmente, y detalla después la única que no dispone de página de integración propia: la contraseña de un solo uso enviada por correo electrónico.
Cuatro factores, no el cuadro completo
Estos cuatro son los que recorre esta página, pero no son los únicos segundos factores que la plataforma puede solicitar. También están disponibles, y quedan fuera del alcance de esta página:
- un OTP enviado por SMS, a través de uno de los numerosos operadores que ofrece el módulo OTP Token Generators;
- un conector Radius hacia una solución MFA de terceros, mediante el tipo OTP - Radius de ese mismo módulo;
- la autenticación mediante certificado x509, que no es un token sino un método de autenticación del propio dominio — User certificate, o User certificate and form para conservar también la contraseña;
- una MFA impuesta aguas arriba por un proveedor SAML, o por cualquier otra autenticación delegada. El segundo factor se solicita entonces antes de que intervenga la plataforma, que no lo configura ni lo ve.
La MFA se define en el dominio de autenticación, nunca en un usuario
Sea cual sea el factor elegido, se habilita en un dominio de autenticación y se aplica a todos los usuarios que inician sesión a través de él. No existe ningún ajuste por usuario: para someter a MFA solo a una parte de su población, sitúe a esos usuarios detrás de un dominio de autenticación específico.
Elegir un factor¶
| Factor | Qué hace el usuario | Qué requiere | Procedimiento |
|---|---|---|---|
| Neomia Pulse | Nada. Se reconoce al usuario por su forma de teclear. | La opción Neomia Pulse, los parámetros de conexión a su servicio Pulse, un dominio de autenticación de tipo local o LDAP, y un segundo factor de esta tabla en ese mismo dominio. |
Integración de Neomia Pulse |
| FIDO2 | Presenta su autenticador — conectando una clave de seguridad, o aprobando en el dispositivo o en la bóveda que guarda la passkey — y escribe después un PIN si el autenticador lo solicita. | Un autenticador FIDO2 por usuario, una relying party declarada en la consola y una cuenta personal — se excluye un dominio de autenticación anónimo. | Integración de Yubico |
| TOTP | Lee un código de seis cifras en una aplicación de autenticación. | Una aplicación en el teléfono o en el puesto de trabajo del usuario (Google Authenticator, FreeOTP, Microsoft Authenticator, etc.) y un registro por usuario. | Integración de Google Authenticator |
| OTP por correo electrónico | Copia un código recibido por correo electrónico. | Un servidor SMTP accesible por la plataforma y una dirección de correo electrónico guardada en un atributo de usuario. | Configurar un OTP por correo electrónico |
Neomia Pulse se configura encima de otro factor
Habilitar Neomia Pulse exige que otra MFA esté habilitada en ese mismo dominio. Sus ajustes deciden después para qué sirve ese otro factor: puede omitirse cuando Pulse valida al usuario y exigirse cuando Pulse no lo valida. Neomia Pulse es, por tanto, una forma de ahorrar el segundo factor más que de sustituirlo.
Dónde se declara cada factor y dónde se habilita¶
La configuración consta de dos etapas posibles — declarar el factor en su propio módulo y habilitarlo después en el dominio de autenticación — pero dos de los cuatro se saltan una de ellas:
| Factor | Declarado en | Habilitado en el dominio de autenticación |
|---|---|---|
| Neomia Pulse | nada que declarar | ✅ la opción Enable neomia Pulse authentication, más los parámetros de conexión al servicio Pulse — véase la nota siguiente |
| FIDO2 | Relying parties | ❌ nada que habilitar — véase la nota siguiente |
| TOTP | OTP Token Generators | ✅ como token de autenticación |
| OTP por correo electrónico | un SMTP server, y después OTP Token Generators | ✅ como token de autenticación |
FIDO2 no tiene ningún interruptor en el dominio de autenticación
Las claves de seguridad no se habilitan proveedor por proveedor: la plataforma ofrece el factor en cuanto hay declarada al menos una relying party, en todos los dominios de autenticación que no sean anónimos — una clave debe estar vinculada a una cuenta personal. Y es el usuario quien registra su autenticador desde el portal, no el administrador quien se lo asigna.
Neomia Pulse no requiere ninguna declaración previa
Pulse no es un token que haya que crear en un módulo: la opción se habilita directamente en el dominio de autenticación, que es también donde se define su comportamiento.
Pulse necesita sus parámetros de conexión
Marcar Enable neomia Pulse authentication muestra tres campos obligatorios que apuntan la plataforma hacia su servicio Pulse:
| Campo | Qué introducir |
|---|---|
| API URL | URL de la API de Pulse. |
| Authentication API URL | URL de la API de autenticación de Pulse. |
| API key | Clave que autentica la plataforma ante ese servicio. |
El dominio de autenticación no se guarda mientras los tres no estén rellenos.
El resto de esta página cubre el OTP por correo electrónico de principio a fin. Los otros tres factores se tratan en su página de integración, enlazada en la tabla anterior.
Configurar un OTP por correo electrónico¶
Un OTP por correo electrónico envía al usuario un código de un solo uso por correo electrónico una vez aceptados su identificador y su contraseña. El usuario introduce ese código en el portal para terminar de iniciar sesión.
Antes de empezar: qué protege realmente un OTP por correo electrónico¶
Un OTP por correo electrónico no siempre añade un factor
Lea esto antes de elegir este factor en lugar de los otros tres.
Si el usuario inicia sesión con su cuenta de Active Directory y recoge el código en un buzón vinculado a esa misma cuenta, el segundo factor apenas aporta nada: un atacante que haya obtenido las credenciales abre el buzón con esas mismas credenciales y lee el código.
Merece la pena desplegar un OTP por correo electrónico cuando no se puede acceder al buzón con las credenciales que se están comprobando, es decir, cuando:
- el usuario inicia sesión con una cuenta local, o con una cuenta distinta de la de su buzón;
- el código se envía a una dirección distinta de la que pertenece a la cuenta de inicio de sesión.
Paso 1 — Disponer de un servidor SMTP¶
La plataforma envía el código a través de un servidor SMTP declarado en el módulo SMTP servers. Si todavía no hay ninguno disponible, declare uno antes de seguir adelante:
Configurar el envío de correos electrónicos
Utilice después el cuadro Configuration test de ese módulo para confirmar la entrega: un fallo diagnosticado en esta fase es un fallo que no tendrá que buscar más tarde en el flujo de inicio de sesión.
El mensaje de prueba no utiliza el remitente que va a configurar
La prueba se envía desde noreply@cleanroom.com, una dirección escrita en el producto: no puede modificarse en ningún sitio y sirve además de dirección de respuesta. Su propio remitente es el SMTP sender del token, definido en el paso 2 — es el que llevan los mensajes OTP reales.
Conviene conocer la consecuencia antes de sacar conclusiones: un servidor SMTP que restrinja las direcciones de envío puede rechazar la prueba y dejar pasar los mensajes reales, y a la inversa.
La conexión la abre la plataforma
El flujo hacia el servidor SMTP parte de la plataforma, no del puesto de trabajo del usuario. Si su servidor SMTP se encuentra en su LAN, ese flujo debe estar autorizado.
Paso 2 — Crear el token OTP¶
Abra el módulo OTP Token Generators y haga clic en +. En la ventana Add OTP token, seleccione el tipo OTP - email y rellene después los campos.
| Campo | Qué introducir |
|---|---|
| OTP Type | OTP - email. Esta elección no puede cambiarse después: un canal distinto significa un token distinto. |
| Name | El nombre del token. Se muestra al usuario en el portal, por lo que debe leerse como un nombre de factor y no como una referencia interna. |
| Description | Texto libre, visible únicamente para los administradores. |
| OTP usable characters | El alfabeto del que se extrae el código. |
| OTP Length | El número de caracteres del código. |
| Validity period of a token (seconds) | El tiempo del que dispone el usuario para introducir el código antes de que se rechace. |
| Message before the OTP | La frase que precede al código en el cuerpo del mensaje. |
| Mail subject | El asunto del mensaje. |
| SMTP sender | La dirección del remitente del mensaje. |
| SMTP server | El servidor declarado en el paso 1. |
La lista completa de los campos, con sus valores predeterminados y sus restricciones, se encuentra en la página de referencia: Bloque genérico y Envío por correo electrónico.
Haga clic en Validate para guardar el token.
Paso 3 — Habilitar el token en un dominio de autenticación¶
Abra el módulo Authentication domain y modifique el dominio que debe solicitar el OTP.
| Campo | Qué introducir |
|---|---|
| Authentication token | El token creado en el paso 2. Pueden seleccionarse varios tokens. |
| User attribute used to send the OTP | El nombre del atributo de usuario que contiene la dirección a la que se envía el código. |
| Token expiration duration | El tiempo durante el cual un OTP validado sigue siendo aceptado antes de volver a solicitarse. 0 desactiva la expiración, lo que significa que el OTP se solicita en cada inicio de sesión. |
| Time unit | Hours o Days, aplicado al campo anterior. |
| Expiration starts | Si la cuenta atrás empieza en la última validación del OTP o en el último inicio de sesión correcto. |
Qué atributo contiene la dirección
El atributo es el del directorio al que apunta el dominio de autenticación, no un nombre elegido por nosotros: utilice el atributo en el que sus usuarios llevan realmente una dirección. En un directorio local, hay que apuntar a la dirección introducida en las propiedades del usuario; en un directorio LDAP, es el atributo de correo propio del directorio.
Haga clic en Validate. A los usuarios de ese dominio de autenticación se les solicitará un código en su siguiente inicio de sesión.
Paso 4 — Compruébelo primero en un dominio de autenticación de prueba¶
Habilitar la MFA en un dominio de autenticación la aplica a todos los usuarios que hay detrás de él, incluido usted mismo si inicia sesión a través de él. Antes de habilitar el token en su dominio de producción, cree un dominio de autenticación de prueba con una sola cuenta y realice a través de él un inicio de sesión completo: identificador, contraseña, recepción del mensaje e introducción del código.
Un usuario sin dirección nunca recibe ningún código
A un usuario cuyo atributo está vacío no se le puede enviar nada, y su inicio de sesión no puede completarse. Compruebe que el atributo está relleno en todas las cuentas que hay detrás del dominio de autenticación antes de habilitar el token en él.