FortiGate VPN MFA: token locale, RADIUS o SAML?

Il gateway, un backend RADIUS o un provider SAML possono verificare il fattore, e ciascuno fallisce in modo diverso. Allineare servizio, client e percorso di ripristino.

Ogni progetto di FortiGate VPN MFA risponde prima a una domanda: chi verifica il secondo fattore? Il gateway stesso può farlo con un token locale o un codice inviato per email, un backend RADIUS può imporlo e restituire una sfida, oppure un provider di identità SAML può assumersi l'intera cerimonia in un browser. Ciascuno produce una sequenza di accesso diversa, una firma di guasto diversa e una procedura di ripristino diversa, e copiare un blocco di comandi dall'uno all'altro produce una configurazione che sembra plausibile e non autentica nessuno. Questo è un articolo sul meccanismo: cosa fa realmente ogni progetto durante un accesso e dove si rompe.

La cerimonia di accesso decide chi possiede il fattore

Nei primi due progetti il FortiGate è la parte che si fida. Raccoglie la credenziale, decide se serve un secondo fattore e lo verifica localmente o tramite una sfida. Nel terzo progetto il gateway smette di essere il verificatore e diventa un relè: reindirizza il client al provider di identità, riceve un'asserzione e mappa l'identità affermata su un utente e un gruppo. Nel progetto RADIUS si colloca nel mezzo e guida uno scambio richiesta-risposta con un backend che detiene la politica.

Questa differenza decide quali prove potete raccogliere. Quando il gateway verifica, il suo output di debug vi dice cos'è successo. Quando verifica un provider di identità, il gateway sa solo che è arrivata un'asserzione, e la risposta a «l'MFA era davvero richiesto» sta nei log del provider, non in quelli del firewall. Leggere il log sbagliato è il modo più comune di diagnosticare male un'implementazione che si comporta esattamente come progettato. Anche il servizio delimita la cerimonia: FortiOS 7.6.3 rimuove la modalità tunnel di SSL VPN a favore di IPsec, mentre la modalità web continua come Agentless VPN sui modelli supportati, quindi una cerimonia provata su un servizio non è automaticamente disponibile su un altro.

Verifica locale: token e codici via email

I fattori gestiti da FortiGate sono associati all'oggetto utente. Un FortiToken o un'integrazione di token documentata richiede registrazione, la cerimonia di verifica supportata, licenze dove applicabile e una procedura di sostituzione. Un codice inviato via email richiede un percorso SMTP funzionante e una casella di posta raggiungibile dall'utente prima che esista il tunnel, una dipendenza che non ha nulla a che fare con la crittografia e tutto a che fare con la possibilità di accedere.

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

La consegna dell'email fa parte della disponibilità dell'autenticazione. Una casella raggiungibile solo tramite VPN crea un ciclo che non si risolve per nessuno, e il ritardo di consegna, la validità del codice e il timeout dell'autenticazione remota sono tre vincoli separati. Alzarne uno non ripara una casella irraggiungibile, e un progetto che non ha mai testato il ciclo lo scoprirà al primo ripristino della password dopo una vacanza.

Anche i requisiti di garanzia appartengono a questa fase, prima della scelta del prodotto. NIST SP 800-63B considera l'email inaccettabile per l'autenticazione fuori banda, quindi un'implementazione che dichiara conformità non può usare un codice email come secondo fattore, per quanto sia comodo. Che una funzione esista sull'apparecchio non dichiara che soddisfi un dato standard.

RADIUS: il gateway chiede, il backend decide

Con RADIUS il FortiGate invia la credenziale a un backend che possiede la politica dei fattori. Lo scambio può essere una semplice accettazione o un rifiuto, oppure può comportare una sfida a cui il client deve rispondere, il che significa che sia il servizio VPN sia il client devono supportare quella forma di sfida. Un backend che impone un'approvazione push e un client che sa solo aggiungere un codice a sei cifre a una password non si incontreranno a metà strada.

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>

Testate il backend in modo indipendente prima di incolpare il tunnel. Se il test authserver riesce e un accesso VPN no, la differenza è nella gestione della sfida e non nella credenziale, e il debug del demone di autenticazione del gateway è il punto in cui questo si vede:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: il browser lascia il gateway

In un progetto SAML il client viene reindirizzato al provider di identità, si autentica lì e torna con un'asserzione che il gateway convalida rispetto a una relazione di fiducia e a una mappatura dei gruppi. Il gateway non vede mai la password né il secondo fattore, il che è allo stesso tempo un miglioramento della sicurezza e una complicazione operativa: il guasto ora avviene in una sessione browser che il firewall non può ispezionare.

Accettare un'asserzione non dimostra che il provider abbia richiesto l'MFA per quell'accesso. Una politica del provider che applica l'MFA ad alcune applicazioni e non ad altre produrrà esattamente l'accesso richiesto e nulla della garanzia presunta. Verificate la politica del provider per questa specifica applicazione e verificate che la mappatura delle attestazioni di gruppo sui gruppi FortiGate corrisponda ancora dopo qualsiasi rinomina su entrambi i lati.

Il supporto del client conta qui più che altrove. Alcuni client VPN gestiscono nativamente il passaggio al browser, altri aprono il browser di sistema, e i client senza interfaccia o da riga di comando potrebbero non completare affatto il flusso. Testate con il client che gli utenti eseguono davvero, sulle piattaforme che usano davvero, prima di pubblicare il profilo.

Il ripristino fa parte del meccanismo

Ogni progetto sopra ha una dipendenza che può fallire per un utente alla volta: una casella irraggiungibile, un token perso, un backend che rifiuta una sfida, un account del provider di identità bloccato. Decidete ora chi può ripristinare l'accesso, con quale procedura supportata e con quale verifica della persona che lo richiede. Un account amministratore locale di emergenza tenuto separato dal percorso VPN è un controllo; e un aggiramento inspiegato con la sola password è un incidente in attesa di essere scoperto.

Poi testate tre accessi prima del rilascio: quello normale, un fattore rifiutato o scaduto e il ripristino approvato di un autenticatore perso. Annotate in quale log compare ciascuno. È quella registrazione che trasforma «l'MFA è attivo» in un progetto che qualcun altro può gestire.

Articoli correlati