FortiGate VPN MFA: lokální token, RADIUS, nebo SAML?

Brána, backend RADIUS i poskytovatel SAML mohou ověřit faktor a každý selhává jinak. Sladit službu, klienta a cestu obnovy.

Každý návrh FortiGate VPN MFA nejprve odpovídá na jednu otázku: kdo ověřuje druhý faktor? Samotná brána to může udělat lokálním tokenem nebo kódem zaslaným e-mailem, backend RADIUS to může vynutit a vrátit výzvu, nebo poskytovatel identity SAML může převzít celý obřad v prohlížeči. Každý z nich vytváří jinou posloupnost přihlášení, jiný podpis selhání a jiný postup obnovy, a kopírování bloku příkazů mezi nimi vede ke konfiguraci, která vypadá věrohodně a nikoho neověří. Toto je článek o mechanismu: co každý návrh při přihlášení skutečně dělá a kde se láme.

Obřad přihlášení rozhoduje, kdo vlastní faktor

V prvních dvou návrzích je FortiGate strana, která důvěřuje. Shromažďuje přihlašovací údaj, rozhoduje, zda je druhý faktor nutný, a ověřuje ho lokálně nebo pomocí výzvy. Ve třetím návrhu brána přestává být ověřovatelem a stává se přeposílatelem: přesměruje klienta k poskytovateli identity, obdrží tvrzení a namapuje potvrzenou identitu na uživatele a skupinu. V návrhu RADIUS stojí mezi nimi a vede výměnu požadavek–odpověď s backendem, který drží politiku.

Tento rozdíl určuje, jaké důkazy můžete shromáždit. Když brána ověřuje, její vlastní ladicí výstup vám řekne, co se stalo. Když ověřuje poskytovatel identity, brána ví jen to, že dorazilo tvrzení, a odpověď na otázku „byl MFA skutečně vyžadován“ žije v protokolech poskytovatele, nikoli v protokolech firewallu. Čtení špatného protokolu je nejčastější způsob, jak chybně diagnostikovat nasazení, které se chová přesně podle návrhu. Samotná služba obřad také omezuje: FortiOS 7.6.3 odstraňuje tunelový režim SSL VPN ve prospěch IPsec, zatímco webový režim pokračuje jako Agentless VPN na podporovaných modelech, takže obřad ověřený na jedné službě není automaticky dostupný na jiné.

Lokální ověření: tokeny a kódy e-mailem

Faktory spravované FortiGate se vážou na objekt uživatele. FortiToken nebo dokumentovaná integrace tokenu vyžaduje registraci, podporovaný ověřovací obřad, licencování tam, kde se uplatňuje, a postup nahrazení. Kód e-mailem vyžaduje funkční cestu SMTP a schránku, ke které se uživatel dostane dřív, než tunel existuje, což je závislost, která nemá nic společného s kryptografií a všechno s tím, zda se někdo může přihlásit.

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

Doručování e-mailů je součástí dostupnosti autentizace. Schránka dostupná jen přes VPN vytváří smyčku, která se pro nikoho nevyřeší sama, a zpoždění doručení, platnost kódu a časový limit vzdálené autentizace jsou tři oddělená omezení. Zvýšení jednoho neopraví nedostupnou schránku a návrh, který smyčku nikdy netestoval, ji objeví při prvním resetu hesla po dovolené.

Požadavky na záruku patří také sem, ještě před volbou produktu. NIST SP 800-63B považuje e-mail za nepřijatelný pro autentizaci mimo pásmo, takže nasazení, které tvrdí shodu, nemůže použít e-mailem zaslaný kód jako druhý faktor, ať je jakkoli pohodlný. Existence funkce v zařízení není prohlášením, že funkce splňuje daný standard.

RADIUS: brána se ptá, backend rozhoduje

S RADIUS posílá FortiGate přihlašovací údaj backendu, který vlastní politiku faktorů. Výměna může být prosté přijetí nebo odmítnutí, nebo může zahrnovat výzvu, na kterou musí klient odpovědět, což znamená, že VPN služba i klient musí tento tvar výzvy podporovat. Backend, který vynucuje push schválení, a klient, který umí jen připojit šestimístný kód k heslu, se uprostřed nesejdou.

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, než obviníte tunel. Pokud test authserver uspěje a přihlášení VPN ne, rozdíl je ve zpracování výzvy, nikoli v přihlašovacím údaji, a ladicí výstup autentizačního démona brány je místo, kde se to ukáže:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: prohlížeč opouští bránu

V návrhu SAML je klient přesměrován k poskytovateli identity, tam se autentizuje a vrací se s tvrzením, které brána ověřuje proti vztahu důvěry a mapování skupin. Brána nikdy nevidí heslo ani druhý faktor, což je zároveň bezpečnostní zlepšení i provozní komplikace: selhání nyní nastává v relaci prohlížeče, kterou firewall nemůže prozkoumat.

Přijetí tvrzení nedokazuje, že poskytovatel pro toto přihlášení MFA vyžadoval. Politika poskytovatele, která uplatňuje MFA na některé aplikace a na jiné ne, vytvoří přesně to přihlášení, které jste chtěli, a nic ze záruky, kterou jste předpokládali. Zkontrolujte politiku poskytovatele pro tuto konkrétní aplikaci a zkontrolujte, že mapování skupinových tvrzení na skupiny FortiGate stále odpovídá po jakémkoli přejmenování na kterékoli straně.

Podpora klienta je zde důležitější než kdekoli jinde. Někteří klienti VPN zvládají předání do prohlížeče nativně, jiní otevírají systémový prohlížeč a klienti bez rozhraní nebo příkazové řádky nemusí tok vůbec dokončit. Testujte s klientem, který uživatelé skutečně používají, na platformách, které skutečně používají, než profil zveřejníte.

Obnova je součástí mechanismu

Každý výše uvedený návrh má závislost, která může selhat pro jednoho uživatele najednou: nedostupná schránka, ztracený token, backend, který odmítá výzvu, uzamčený účet poskytovatele identity. Rozhodněte teď, kdo může obnovit přístup, jakým podporovaným postupem a s jakým ověřením žádající osoby. Nouzový lokální administratorský účet držený odděleně od cesty VPN je kontrola; a nevysvětlené obejití pouze heslem je incident čekající na objevení.

Poté před nasazením otestujte tři přihlášení: běžné, odmítnutý nebo propadlý faktor a schválenou obnovu ztraceného autentikátoru. Zaznamenejte, ve kterém protokolu se každé objeví. Právě tento záznam mění „MFA je zapnuto“ v návrh, který může provozovat někdo jiný.

Související články