FortiGate VPN MFA: token local, RADIUS sau SAML?

Gateway-ul, un backend RADIUS sau un furnizor SAML pot verifica factorul, iar fiecare eșuează diferit. Aliniați serviciul, clientul și calea de recuperare.

Fiecare proiect FortiGate VPN MFA răspunde mai întâi la o întrebare: cine verifică al doilea factor? Gateway-ul însuși o poate face cu un token local sau cu un cod trimis prin e-mail, un backend RADIUS îl poate impune și returna o provocare, sau un furnizor de identitate SAML poate prelua întreaga ceremonie într-un browser. Fiecare dintre ele produce o secvență de autentificare diferită, o semnătură de eșec diferită și o procedură de recuperare diferită, iar copierea unui bloc de comenzi între ele produce o configurație care pare plauzibilă și nu autentifică pe nimeni. Acesta este un articol despre mecanism: ce face fiecare proiect efectiv în timpul autentificării și unde se rupe.

Ceremonia de autentificare decide cine deține factorul

În primele două proiecte, FortiGate este partea care are încredere. Colectează acreditările, decide dacă este necesar un al doilea factor și îl verifică local sau printr-o provocare. În al treilea proiect, gateway-ul încetează să mai fie verificator și devine un releu: redirecționează clientul către furnizorul de identitate, primește o aserțiune și mapează identitatea confirmată la un utilizator și un grup. În proiectul RADIUS se află între ele și conduce un schimb cerere-răspuns cu un backend care deține politica.

Această diferență decide ce dovezi puteți colecta. Când gateway-ul verifică, ieșirea sa de depanare vă spune ce s-a întâmplat. Când verifică un furnizor de identitate, gateway-ul știe doar că a sosit o aserțiune, iar răspunsul la «a fost MFA cu adevărat necesar» se află în jurnalele furnizorului, nu în cele ale firewall-ului. Citirea jurnalului greșit este cea mai frecventă cale de a diagnostica greșit o implementare care se comportă exact cum a fost proiectată. Serviciul însuși limitează și ceremonia: FortiOS 7.6.3 elimină modul tunel al SSL VPN în favoarea IPsec, în timp ce modul web continuă ca Agentless VPN pe modelele acceptate, astfel încât o ceremonie dovedită pe un serviciu nu este automat disponibilă pe altul.

Verificare locală: tokenuri și coduri prin e-mail

Factorii administrați de FortiGate sunt atașați obiectului de utilizator. Un FortiToken sau o integrare de token documentată necesită înregistrare, ceremonia de verificare acceptată, licențiere unde se aplică și o procedură de înlocuire. Un cod trimis prin e-mail necesită o cale SMTP funcțională și o căsuță poștală pe care utilizatorul o poate accesa înainte ca tunelul să existe, o dependență care nu are nimic de-a face cu criptografia și totul de-a face cu posibilitatea ca cineva să se conecteze.

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

Livrarea e-mailului face parte din disponibilitatea autentificării. O căsuță accesibilă doar prin VPN creează o buclă care nu se rezolvă singură pentru nimeni, iar întârzierea livrării, valabilitatea codului și expirarea autentificării la distanță sunt trei constrângeri separate. Creșterea uneia nu repară o căsuță inaccesibilă, iar un proiect care nu a testat niciodată bucla o va descoperi la prima resetare de parolă după o vacanță.

Cerințele de asigurare aparțin și ele aici, înainte de alegerea produsului. NIST SP 800-63B consideră e-mailul inacceptabil pentru autentificarea în afara benzii, așa că o implementare care revendică conformitate nu poate folosi un cod prin e-mail ca al doilea factor, oricât de convenabil ar fi. Existența unei funcții pe dispozitiv nu este o declarație că funcția satisface un standard dat.

RADIUS: gateway-ul întreabă, backend-ul decide

Cu RADIUS, FortiGate trimite acreditările unui backend care deține politica factorilor. Schimbul poate fi o simplă acceptare sau respingere, sau poate implica o provocare la care clientul trebuie să răspundă, ceea ce înseamnă că atât serviciul VPN, cât și clientul trebuie să accepte acea formă de provocare. Un backend care impune o aprobare push și un client care știe doar să adauge un cod de șase cifre la o parolă nu se vor întâlni la mijloc.

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>

Testați backend-ul independent înainte de a da vina pe tunel. Dacă testul authserver reușește și o autentificare VPN nu, diferența este în tratarea provocării și nu în acreditări, iar depanarea demonului de autentificare al gateway-ului este locul unde acest lucru se vede:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: browserul părăsește gateway-ul

Într-un proiect SAML, clientul este redirecționat către furnizorul de identitate, se autentifică acolo și revine cu o aserțiune pe care gateway-ul o validează față de o relație de încredere și o mapare de grupuri. Gateway-ul nu vede niciodată parola sau al doilea factor, ceea ce este simultan o îmbunătățire de securitate și o complicație operațională: eșecul are loc acum într-o sesiune de browser pe care firewall-ul nu o poate inspecta.

Acceptarea unei aserțiuni nu dovedește că furnizorul a cerut MFA pentru acea autentificare. O politică a furnizorului care aplică MFA unor aplicații și nu altora va produce exact autentificarea cerută și nimic din asigurarea presupusă. Verificați politica furnizorului pentru această aplicație concretă și verificați că maparea afirmațiilor de grup către grupurile FortiGate încă se potrivește după orice redenumire de orice parte.

Suportul clientului contează aici mai mult decât oriunde. Unii clienți VPN gestionează nativ predarea către browser, alții deschid browserul sistemului, iar clienții fără interfață sau din linia de comandă pot să nu finalizeze deloc fluxul. Testați cu clientul pe care utilizatorii îl rulează efectiv, pe platformele pe care le folosesc efectiv, înainte de a publica profilul.

Recuperarea face parte din mecanism

Fiecare proiect de mai sus are o dependență care poate eșua pentru un singur utilizator odată: o căsuță inaccesibilă, un token pierdut, un backend care respinge o provocare, un cont de furnizor de identitate blocat. Decideți acum cine poate restabili accesul, prin ce procedură acceptată și cu ce verificare a persoanei care îl cere. Un cont de administrator local de urgență ținut separat de calea VPN este un control; iar o ocolire neexplicată doar cu parolă este un incident care așteaptă să fie descoperit.

Apoi testați trei autentificări înainte de implementare: cea normală, un factor respins sau expirat și recuperarea aprobată a unui autentificator pierdut. Notați în ce jurnal apare fiecare. Acea evidență este cea care transformă «MFA este activat» într-un proiect pe care altcineva îl poate opera.

Articole similare