El servicio MFA cae: decida el acceso a la VPN antes del fallo

El acceso a la VPN se detiene y la alerta dice que el servicio de segundo factor no está disponible. Si alguien todavía puede conectarse es una cuestión de política que debía responderse antes de la interrupción, no durante ella. Un verificador no disponible no es prueba de que un factor haya pasado, y un desafío rechazado no es el mismo suceso que uno inalcanzable. El manual siguiente convierte esa distinción en una regla escrita que puede probar.

Paso 1: nombre los tres resultados por separado

Escriba tres estados y niéguese a fusionarlos: la autenticación primaria falló, el desafío del segundo factor fue denegado o expiró, y el servicio MFA nunca respondió. Cada uno tiene un propietario distinto, una línea de registro distinta y una respuesta correcta distinta. Un solo mensaje genérico de tiempo agotado oculta en cuál está, y esa ambigüedad es lo que convierte una interrupción en una discusión. Nombre los estados en el manual antes de necesitarlos.

Una denegación significa que el verificador respondió y dijo no, lo que es un resultado de política y no un problema de disponibilidad. Un intento expirado significa que el desafío existía y nadie lo completó a tiempo. Un servicio inalcanzable significa que la pregunta nunca se respondió. Solo el tercero es una interrupción.

Paso 2: lea el modo de fallo que el proxy usa realmente

Encuentre el ajuste que gobierna el comportamiento cuando no se puede contactar con el servicio y léalo desde la configuración en ejecución, no desde una plantilla. En el proxy RADIUS de Duo, los valores documentados de failmode son safe y secure, con safe permitiendo un intento solo cuando la autenticación primaria tiene éxito y secure rechazando el intento en esa condición.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

El nombre safe describe una elección de disponibilidad, no una garantía de que cada sesión admitida tuviera un segundo factor reciente. Esa frase pertenece al registro de riesgos, porque es exactamente la contrapartida que hace el ajuste. No generalice el valor a otro proveedor, otra integración u otro modo de proxy; lea la documentación de ese producto para su propio equivalente. Una configuración copiada de un ejemplo de proveedor sin este entendimiento es una sorpresa esperando la próxima interrupción.

Deténgase si nadie puede decir qué modo está activo. El resto del manual depende de esa respuesta.

Paso 3: haga que los reintentos coincidan con el flujo

Alinee el tiempo de espera y el comportamiento de reintento de la puerta de enlace con el flujo de autenticación que conduce. Los reintentos no coordinados crean múltiples avisos, confunden el emparejamiento de intentos y dejan al registro sin poder decir qué resultado corresponde a qué inicio de sesión. Un tiempo de espera muy largo no es un diseño de disponibilidad; es una espera más larga para la misma respuesta.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

El tiempo de espera propio de la solicitud del proxy es un límite aparte: una solicitud de autenticación que se emite y nunca se completa se rechaza, y ese rechazo no es una interrupción de la que retroceder. Trate una denegación, un desafío sin terminar y un servicio inalcanzable como tres entradas distintas en su tabla de decisiones. Luego haga explícita la tabla: qué estado admite, qué estado retiene y qué estado escala a una persona.

Si dos componentes reintentan ambos, corrija primero la propiedad de los reintentos. Los avisos duplicados son un síntoma de dos propietarios, no de un servicio lento.

Paso 4: gobierne el acceso de emergencia por separado

Si se requiere acceso de emergencia, dele su propio alcance, identidad, autorización y rastro de auditoría. Desactivar MFA en silencio para todos los usuarios no es un procedimiento de emergencia; es un debilitamiento permanente con un incidente adjunto. El propietario de seguridad aprueba de antemano la regla de admisión, la visibilidad y la ruta de escalada.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Pruebe toda la matriz en un entorno que no sea de producción: fallo primario, rechazo deliberado, caducidad del desafío e indisponibilidad del servicio. Para cada uno, registre el resultado de admisión y el motivo que se registró. No cree una interrupción de producción para descubrir el comportamiento configurado, y no pruebe la ruta de emergencia por primera vez durante el incidente para el que se escribió. Un procedimiento de recuperación que nunca se ha ejecutado es un documento, no un control.

El manual termina cuando los tres estados están nombrados, el modo de fallo se ha leído del sistema en ejecución, los reintentos tienen un solo propietario y el acceso de emergencia tiene su propia aprobación y revisión. La aplicación predecible más una ruta de recuperación conocida es el resultado que vale la pena documentar.