O servizo MFA cae: decida o acceso á VPN antes do fallo

O acceso á VPN detense e a alerta di que o servizo de segundo factor non está dispoñible. Se alguén aínda pode conectarse é unha cuestión de política que debía responderse antes da interrupción, non durante ela. Un verificador non dispoñible non é proba de que un factor pasase, e un desafío rexeitado non é o mesmo suceso ca un inalcanzable. O manual seguinte converte esa distinción nunha regra escrita que pode probar.

Paso 1: nomee os tres resultados por separado

Escriba tres estados e néguese a fusionalos: a autenticación primaria fallou, o desafío do segundo factor foi denegado ou caducou, e o servizo MFA nunca respondeu. Cada un ten un propietario distinto, unha liña de rexistro distinta e unha resposta correcta distinta. Unha soa mensaxe xenérica de tempo esgotado oculta en cal está, e esa ambigüidade é o que converte unha interrupción nunha discusión. Nomee os estados no manual antes de necesitalos.

Unha denegación significa que o verificador respondeu e dixo non, o que é un resultado de política e non un problema de dispoñibilidade. Un intento caducado significa que o desafío existía e ninguén o completou a tempo. Un servizo inalcanzable significa que a pregunta nunca se respondeu. Só o terceiro é unha interrupción.

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

Atope o axuste que goberna o comportamento cando non se pode contactar co servizo e léao desde a configuración en execución, non desde un modelo. No proxy RADIUS de Duo, os valores documentados de failmode son safe e secure, con safe permitindo un intento só cando a autenticación primaria ten éxito e secure rexeitando o intento nesa condición.

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

O nome safe describe unha elección de dispoñibilidade, non unha garantía de que cada sesión admitida tivese un segundo factor recente. Esa frase pertence ao rexistro de riscos, porque é exactamente a contrapartida que fai o axuste. Non xeneralice o valor a outro provedor, outra integración ou outro modo de proxy; lea a documentación dese produto para o seu propio equivalente. Unha configuración copiada dun exemplo de provedor sen este entendemento é unha sorpresa que espera a próxima interrupción.

Détase se ninguén pode dicir que modo está activo. O resto do manual depende desa resposta.

Paso 3: faga que os reintentos coincidan co fluxo

Aliñe o tempo de espera e o comportamento de reintento da pasarela co fluxo de autenticación que conduce. Os reintentos non coordinados crean múltiples avisos, confunden o emparellamento de intentos e deixan o rexistro sen poder dicir que resultado corresponde a que inicio de sesión. Un tempo de espera moi longo non é un deseño de dispoñibilidade; é unha espera máis longa para a mesma resposta.

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

O tempo de espera propio da solicitude do proxy é un límite aparte: unha solicitude de autenticación que se emite e nunca se completa rexéitase, e ese rexeitamento non é unha interrupción da que retroceder. Trate unha denegación, un desafío sen terminar e un servizo inalcanzable como tres entradas distintas na súa táboa de decisións. Despois faga a táboa explícita: que estado admite, que estado retén e que estado escala a unha persoa.

Se dous compoñentes reintentan ambos, corrixa primeiro a propiedade dos reintentos. Os avisos duplicados son un síntoma de dous propietarios, non dun servizo lento.

Paso 4: goberne o acceso de emerxencia por separado

Se se require acceso de emerxencia, déalle o seu propio alcance, identidade, autorización e rastro de auditoría. Desactivar MFA en silencio para todos os usuarios non é un procedemento de emerxencia; é un debilitamento permanente cun incidente unido. O propietario de seguridade aproba de antemán a regra de admisión, a visibilidade e a ruta de escalada.

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

Probe toda a matriz nun ambiente que non sexa de produción: fallo primario, rexeitamento deliberado, caducidade do desafío e indispoñibilidade do servizo. Para cada un, rexistre o resultado de admisión e o motivo que se rexistrou. Non cree unha interrupción de produción para descubrir o comportamento configurado, e non probe a ruta de emerxencia por primeira vez durante o incidente para o que se escribiu. Un procedemento de recuperación que nunca se executou é un documento, non un control.

O manual termina cando os tres estados están nomeados, o modo de fallo se leu do sistema en execución, os reintentos teñen un só propietario e o acceso de emerxencia ten a súa propia aprobación e revisión. A aplicación previsible máis unha ruta de recuperación coñecida é o resultado que paga a pena documentar.