FortiGate VPN MFA: token local, RADIUS ou SAML?

O gateway, um backend RADIUS ou um provedor SAML podem verificar o fator, e cada um falha de forma diferente. Alinhe serviço, cliente e caminho de recuperação.

Todo projeto de FortiGate VPN MFA responde primeiro a uma pergunta: quem verifica o segundo fator? O próprio gateway pode fazê-lo com um token local ou um código enviado por e-mail, um backend RADIUS pode impô-lo e devolver um desafio, ou um provedor de identidade SAML pode assumir toda a cerimônia num navegador. Cada um produz uma sequência de login diferente, uma assinatura de falha diferente e um procedimento de recuperação diferente, e copiar um bloco de comandos entre eles produz uma configuração que parece plausível e não autentica ninguém. Este é um artigo sobre o mecanismo: o que cada projeto realmente faz durante um login e onde ele quebra.

A cerimônia de login decide quem possui o fator

Nos dois primeiros projetos, o FortiGate é a parte que confia. Ele coleta a credencial, decide se um segundo fator é necessário e o verifica localmente ou pedindo um desafio. No terceiro projeto, o gateway deixa de ser o verificador e passa a ser um relé: redireciona o cliente ao provedor de identidade, recebe uma asserção e mapeia a identidade afirmada para um usuário e um grupo. No projeto RADIUS, fica no meio e conduz uma troca de requisição e resposta com um backend que detém a política.

Essa diferença decide quais evidências você pode reunir. Quando o gateway verifica, sua própria saída de depuração diz o que aconteceu. Quando um provedor de identidade verifica, o gateway só sabe que uma asserção chegou, e a resposta a «o MFA era realmente exigido» está nos logs do provedor, não nos do firewall. Ler o log errado é a forma mais comum de diagnosticar mal uma implantação que se comporta exatamente como projetada. O próprio serviço também delimita a cerimônia: O FortiOS 7.6.3 remove o modo túnel do SSL VPN em favor do IPsec, enquanto o modo web continua como Agentless VPN nos modelos suportados, então uma cerimônia comprovada num serviço não está automaticamente disponível noutro.

Verificação local: tokens e códigos por e-mail

Os fatores geridos pelo FortiGate ficam ligados ao objeto de usuário. Um FortiToken ou uma integração de token documentada exige registro, a cerimônia de verificação suportada, licenciamento quando aplicável e um procedimento de substituição. Um código enviado por e-mail exige um caminho SMTP funcional e uma caixa de correio que o usuário consiga alcançar antes de o túnel existir, uma dependência que nada tem a ver com criptografia e tudo a ver com a possibilidade de alguém entrar.

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

A entrega de e-mail é parte da disponibilidade da autenticação. Uma caixa de correio acessível apenas pela VPN cria um ciclo que não se resolve sozinho para ninguém, e o atraso de entrega, a validade do código e o tempo limite da autenticação remota são três restrições separadas. Aumentar uma não repara uma caixa inacessível, e um projeto que nunca testou o ciclo vai descobri-lo no primeiro reset de palavra-passe depois das férias.

Os requisitos de garantia também pertencem aqui, antes da escolha do produto. NIST SP 800-63B considera o e-mail inaceitável para autenticação fora de banda, portanto uma implantação que reivindica conformidade não pode usar um código por e-mail como segundo fator, por mais cómodo que seja. A existência de um recurso no equipamento não declara que o recurso satisfaz um determinado padrão.

RADIUS: o gateway pergunta, o backend decide

Com RADIUS, o FortiGate envia a credencial a um backend que possui a política dos fatores. A troca pode ser uma simples aceitação ou rejeição, ou pode envolver um desafio a que o cliente tem de responder, o que significa que tanto o serviço VPN como o cliente têm de suportar essa forma de desafio. Um backend que impõe uma aprovação push e um cliente que só sabe acrescentar um código de seis dígitos a uma palavra-passe não se encontram a meio caminho.

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>

Teste o backend de forma independente antes de culpar o túnel. Se o teste authserver tiver sucesso e um login VPN não, a diferença está no tratamento do desafio e não na credencial, e a depuração do daemon de autenticação do gateway é onde isso se vê:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: o navegador deixa o gateway

Num projeto SAML, o cliente é redirecionado ao provedor de identidade, autentica-se lá e regressa com uma asserção que o gateway valida face a uma relação de confiança e a um mapeamento de grupos. O gateway nunca vê a palavra-passe nem o segundo fator, o que é ao mesmo tempo uma melhoria de segurança e uma complicação operacional: a falha passa agora a ocorrer numa sessão de navegador que o firewall não consegue inspecionar.

Aceitar uma asserção não prova que o provedor exigiu MFA para esse login. Uma política do provedor que aplica MFA a algumas aplicações e não a outras produzirá exatamente o login pedido e nada da garantia pressuposta. Verifique a política do provedor para esta aplicação concreta e verifique que o mapeamento das afirmações de grupo para os grupos do FortiGate continua a coincidir depois de qualquer mudança de nome em qualquer dos lados.

O suporte do cliente importa aqui mais do que em qualquer outro lugar. Alguns clientes VPN tratam a passagem para o navegador de forma nativa, outros abrem o navegador do sistema, e clientes sem interface ou de linha de comandos podem não concluir o fluxo de todo. Teste com o cliente que os usuários realmente executam, nas plataformas que realmente usam, antes de publicar o perfil.

A recuperação faz parte do mecanismo

Cada projeto acima tem uma dependência que pode falhar para um usuário de cada vez: uma caixa inacessível, um token perdido, um backend que rejeita um desafio, uma conta de provedor de identidade bloqueada. Decida agora quem pode restaurar o acesso, através de que procedimento suportado e com que verificação da pessoa que o pede. Uma conta de administrador local de emergência mantida à parte do caminho VPN é um controlo; e um desvio inexplicado apenas com palavra-passe é um incidente à espera de ser descoberto.

Depois teste três logins antes da implantação: o normal, um fator rejeitado ou expirado e a recuperação aprovada de um autenticador perdido. Registe em que log aparece cada um. É esse registo que transforma «o MFA está ativo» num projeto que outra pessoa consegue operar.

Artigos relacionados