FortiGate VPN MFA: token local, RADIUS ou SAML?

A pasarela, un backend RADIUS ou un provedor SAML poden verificar o factor, e cada un falla de xeito distinto. Axuste o servizo, o cliente e a ruta de recuperación.

Cada deseño de FortiGate VPN MFA responde primeiro unha pregunta: quen verifica o segundo factor? A propia pasarela pode facelo cun token local ou un código enviado por correo, un backend RADIUS pode impoñelo e devolver un desafío, ou un provedor de identidade SAML pode asumir toda a cerimonia nun navegador. Cada opción produce unha secuencia de inicio de sesión distinta, unha sinatura de fallo distinta e un procedemento de recuperación distinto, e copiar un bloque de comandos entre elas produce unha configuración que parece plausible e non autentica a ninguén. Este é un artigo de mecanismo: que fai realmente cada deseño durante un inicio de sesión e onde se rompe.

A cerimonia de inicio de sesión decide quen posúe o factor

Nos dous primeiros deseños, o FortiGate é a parte que confía. Recolle a credencial, decide se se require un segundo factor e verifícao localmente ou mediante un desafío. No terceiro deseño, a pasarela deixa de ser o verificador e convértese nun relé: redirixe o cliente ao provedor de identidade, recibe unha aserción e asigna a identidade afirmada a un usuario e un grupo. No deseño RADIUS queda no medio e impulsa un intercambio de petición e resposta cun backend que ten a política.

Esa diferenza decide que probas pode reunir. Cando a pasarela verifica, a súa propia saída de depuración dille que ocorreu. Cando verifica un provedor de identidade, a pasarela só sabe que chegou unha aserción, e a resposta a «requiríase realmente MFA» vive nos rexistros do provedor, non nos do cortafuegos. Ler o rexistro equivocado é a forma máis habitual de diagnosticar mal un despregamento que se comporta exactamente como se deseñou. O propio servizo tamén delimita a cerimonia: FortiOS 7.6.3 elimina o modo túnel de SSL VPN en favor de IPsec, mentres que o modo web continúa como Agentless VPN nos modelos compatibles, así que unha cerimonia probada nun servizo non está automaticamente dispoñible noutro.

Verificación local: tokens e códigos por correo

Os factores xestionados por FortiGate asócianse ao obxecto de usuario. Un FortiToken ou unha integración de token documentada necesita rexistro, a cerimonia de verificación admitida, licenza cando corresponda e un procedemento de substitución. Un código enviado por correo necesita unha ruta SMTP funcional e unha caixa de correo á que o usuario poida chegar antes de que exista o túnel, unha dependencia que non ten nada que ver coa criptografía e ten todo que ver con se alguén pode iniciar sesión.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

A entrega do correo forma parte da dispoñibilidade da autenticación. Unha caixa accesible só a través da VPN crea un bucle que non se resolve para ninguén, e o atraso de entrega, a validez do código e o tempo de espera da autenticación remota son tres restricións separadas. Elevar unha non repara unha caixa inaccesible, e un deseño que nunca probou o bucle descubrirao durante o primeiro restablecemento de contrasinal tras unhas vacacións.

Os requisitos de aseguramento tamén pertencen aquí, antes da elección do produto. NIST SP 800-63B considera o correo inaceptable para a autenticación fóra de banda, así que un despregamento que afirme conformidade non pode usar un código por correo como segundo factor, por cómodo que sexa. Que unha función exista no dispositivo non declara que esa función cumpra unha norma determinada.

RADIUS: a pasarela pregunta, o backend decide

Con RADIUS, o FortiGate envía a credencial a un backend que posúe a política de factores. O intercambio pode ser unha simple aceptación ou rexeitamento, ou pode implicar un desafío que o cliente debe responder, o que significa que tanto o servizo VPN como o cliente deben admitir esa forma de desafío. Un backend que impón unha aprobación push e un cliente que só sabe engadir un código de seis díxitos a un contrasinal non se atoparán a metade de camiño.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Probe o backend de forma independente antes de culpar o túnel. Se a proba de authserver ten éxito e un inicio de sesión VPN non, a diferenza está no tratamento do desafío e non na credencial, e a depuración do daemon de autenticación da pasarela é onde iso se ve:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: o navegador abandona a pasarela

Nun deseño SAML, o cliente é redirixido ao provedor de identidade, autentícase alí e volve cunha aserción que a pasarela valida contra unha relación de confianza e unha asignación de grupos. A pasarela nunca ve o contrasinal nin o segundo factor, o que é á vez unha mellora de seguridade e unha complicación operativa: o fallo ocorre agora nunha sesión de navegador que o cortafuegos non pode inspeccionar.

Aceptar unha aserción non demostra que o provedor esixise MFA para ese inicio de sesión. Unha política do provedor que aplica MFA a algunhas aplicacións e non a outras producirá exactamente o inicio de sesión que pediu e nada do aseguramento que supuxo. Comprobe a política do provedor para esta aplicación concreta e comprobe que a asignación das afirmacións de grupo aos grupos de FortiGate segue coincidindo tras calquera cambio de nome en calquera dos lados.

O soporte do cliente importa aquí máis que en ningún outro sitio. Algúns clientes VPN xestionan o traspaso ao navegador de forma nativa, outros abren o navegador do sistema, e os clientes sen interface ou de liña de ordes pode que non completen o fluxo. Probe co cliente que os usuarios executan realmente, nas plataformas que realmente usan, antes de publicar o perfil.

A recuperación forma parte do mecanismo

Cada deseño anterior ten unha dependencia que pode fallar para un usuario á vez: unha caixa inaccesible, un token perdido, un backend que rexeita un desafío, unha conta de provedor de identidade bloqueada. Decida agora quen pode restaurar o acceso, mediante que procedemento admitido e con que verificación da persoa que o solicita. Unha conta de administrador local de emerxencia mantida separada da ruta VPN é un control; e unha omisión inexplicada só con contrasinal é un incidente esperando a ser descuberto.

Despois probe tres inicios de sesión antes do despregamento: o normal, un factor rexeitado ou caducado e a recuperación aprobada dun autenticador perdido. Anote en que rexistro aparece cada un. Ese rexistro é o que converte «MFA está activado» nun deseño que outra persoa pode operar.

Artigos relacionados