FortiGate VPN MFA: lokálny token, RADIUS alebo SAML?

Každý návrh FortiGate VPN MFA najprv odpovedá na jednu otázku: kto overuje druhý faktor? Samotná brána to môže urobiť lokálnym tokenom alebo kódom zaslaným e-mailom, backend RADIUS to môže vynútiť a vrátiť výzvu, alebo poskytovateľ identity SAML môže prevziať celú ceremóniu v prehliadači. Každý z nich vytvára inú postupnosť prihlásenia, iný podpis zlyhania a iný postup obnovy, a kopírovanie bloku príkazov medzi nimi vedie ku konfigurácii, ktorá vyzerá vierohodne a nikoho neoverí. Toto je článok o mechanizme: čo každý návrh pri prihlásení skutočne robí a kde sa láme.

Ceremónia prihlásenia rozhoduje, kto vlastní faktor

V prvých dvoch návrhoch je FortiGate strana, ktorá dôveruje. Zhromažďuje prihlasovacie údaje, rozhoduje, či je potrebný druhý faktor, a overuje ho lokálne alebo pomocou výzvy. V treťom návrhu brána prestáva byť overovateľom a stáva sa preposielateľom: presmeruje klienta k poskytovateľovi identity, prijme tvrdenie a namapuje potvrdenú identitu na používateľa a skupinu. V návrhu RADIUS stojí medzi nimi a vedie výmenu požiadavka-odpoveď s backendom, ktorý drží politiku.

Tento rozdiel určuje, aké dôkazy môžete zhromaždiť. Keď brána overuje, jej vlastný ladiaci výstup vám povie, čo sa stalo. Keď overuje poskytovateľ identity, brána vie len to, že prišlo tvrdenie, a odpoveď na otázku „bol MFA skutočne potrebný“ žije v logoch poskytovateľa, nie v logoch firewallu. Čítanie nesprávneho logu je najčastejší spôsob, ako nesprávne diagnostikovať nasadenie, ktoré sa správa presne tak, ako bolo navrhnuté. Samotná služba ceremóniu tiež obmedzuje: FortiOS 7.6.3 odstraňuje tunelový režim SSL VPN v prospech IPsec, zatiaľ čo webový režim pokračuje ako Agentless VPN na podporovaných modeloch, takže ceremónia overená na jednej službe nie je automaticky dostupná na inej.

Lokálne overenie: tokeny a kódy e-mailom

Faktory spravované FortiGate sú naviazané na objekt používateľa. FortiToken alebo dokumentovaná integrácia tokenu vyžaduje registráciu, podporovanú overovaciu ceremóniu, licencovanie tam, kde sa uplatňuje, a postup nahradenia. Kód zaslaný e-mailom vyžaduje funkčnú cestu SMTP a schránku, ku ktorej sa používateľ dostane skôr, než tunel existuje, čo je závislosť, ktorá nemá nič spoločné s kryptografiou a všetko s tým, či sa niekto môže prihlásiť.

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

Doručovanie e-mailov je súčasťou dostupnosti autentifikácie. Schránka dostupná len cez VPN vytvára slučku, ktorá sa pre nikoho nevyrieši sama, a oneskorenie doručenia, platnosť kódu a časový limit vzdialenej autentifikácie sú tri oddelené obmedzenia. Zvýšenie jedného neopraví nedostupnú schránku a návrh, ktorý slučku nikdy netestoval, ju objaví pri prvom resete hesla po dovolenke.

Požiadavky na záruku patria tiež sem, ešte pred voľbou produktu. NIST SP 800-63B považuje e-mail za neprijateľný na autentifikáciu mimo pásma, takže nasadenie, ktoré tvrdí zhodu, nemôže použiť e-mailový kód ako druhý faktor, nech je akokoľvek pohodlný. Existencia funkcie v zariadení nie je vyhlásením, že funkcia spĺňa daný štandard.

RADIUS: brána sa pýta, backend rozhoduje

S RADIUS posiela FortiGate prihlasovacie údaje backendu, ktorý vlastní politiku faktorov. Výmena môže byť jednoduché prijatie alebo odmietnutie, alebo môže zahŕňať výzvu, na ktorú musí klient odpovedať, čo znamená, že VPN služba aj klient musia podporovať taký tvar výzvy. Backend, ktorý vynucuje push schválenie, a klient, ktorý vie len pripojiť šesťmiestny kód k heslu, sa v strede nestretnú.

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>

Otestujte backend nezávisle, skôr než obviníte tunel. Ak test authserver uspeje a prihlásenie VPN nie, rozdiel je v spracovaní výzvy a nie v prihlasovacích údajoch, a ladiaci výstup autentifikačného démona brány je miesto, kde sa to ukáže:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: prehliadač opúšťa bránu

V návrhu SAML je klient presmerovaný k poskytovateľovi identity, tam sa autentifikuje a vracia sa s tvrdením, ktoré brána overuje voči vzťahu dôvery a mapovaniu skupín. Brána nikdy nevidí heslo ani druhý faktor, čo je zároveň bezpečnostné zlepšenie aj prevádzková komplikácia: zlyhanie teraz nastáva v relácii prehliadača, ktorú firewall nemôže preskúmať.

Prijatie tvrdenia nedokazuje, že poskytovateľ pre toto prihlásenie MFA vyžadoval. Politika poskytovateľa, ktorá uplatňuje MFA na niektoré aplikácie a na iné nie, vytvorí presne to prihlásenie, ktoré ste chceli, a nič zo záruky, ktorú ste predpokladali. Skontrolujte politiku poskytovateľa pre túto konkrétnu aplikáciu a skontrolujte, že mapovanie skupinových tvrdení na skupiny FortiGate stále sedí po akomkoľvek premenovaní na ktorejkoľvek strane.

Podpora klienta je tu dôležitejšia než kdekoľvek inde. Niektorí klienti VPN zvládajú odovzdanie do prehliadača natívne, iní otvárajú systémový prehliadač a klienti bez rozhrania alebo príkazového riadka nemusia tok vôbec dokončiť. Testujte s klientom, ktorý používatelia skutočne spúšťajú, na platformách, ktoré skutočne používajú, skôr než profil zverejníte.

Obnova je súčasťou mechanizmu

Každý z vyššie uvedených návrhov má závislosť, ktorá môže zlyhať pre jedného používateľa naraz: nedostupná schránka, stratený token, backend, ktorý odmieta výzvu, uzamknutý účet poskytovateľa identity. Rozhodnite teraz, kto môže obnoviť prístup, akým podporovaným postupom a s akým overením žiadajúcej osoby. Núdzový lokálny administrátorský účet držaný oddelene od cesty VPN je kontrola; a nevysvetlené obídenie iba heslom je incident čakajúci na objavenie.

Potom pred nasadením otestujte tri prihlásenia: bežné, odmietnutý alebo expirovaný faktor a schválenú obnovu strateného autentifikátora. Zaznamenajte, v ktorom logu sa každé objaví. Práve tento záznam mení „MFA je zapnuté“ na návrh, ktorý môže prevádzkovať niekto iný.