FortiGate VPN MFA: локален токен, RADIUS или SAML?

Шлюзът, RADIUS бекендът или SAML доставчикът могат да проверят фактора и всеки се проваля по различен начин. Съгласувайте услугата, клиента и пътя за възстановяване.

Всеки проект за FortiGate VPN MFA първо отговаря на един въпрос: кой проверява втория фактор? Самият шлюз може да го направи с локален токен или код по имейл, RADIUS бекенд може да го наложи и да върне предизвикателство, или SAML доставчик на идентичност може да поеме цялата церемония в браузър. Всяко от тях дава различна последователност на влизане, различен подпис на отказ и различна процедура за възстановяване, а копирането на команден блок между тях създава конфигурация, която изглежда правдоподобна и не удостоверява никого. Това е статия за механизма: какво всъщност прави всеки проект при влизане и къде се чупи.

Церемонията по влизане решава кой притежава фактора

В първите два проекта FortiGate е страната, която се доверява. Той събира идентификационните данни, решава дали е необходим втори фактор и го проверява локално или чрез заявка за предизвикателство. В третия проект шлюзът престава да бъде проверяващ и става ретранслатор: пренасочва клиента към доставчика на идентичност, получава утвърждение и съпоставя утвърдената идентичност с потребител и група. В проекта с RADIUS той е по средата и води обмен заявка-отговор с бекенд, който държи политиката.

Тази разлика решава какви доказателства можете да съберете. Когато шлюзът проверява, собственият му дебъг изход ви казва какво се е случило. Когато проверява доставчик на идентичност, шлюзът знае само, че е пристигнало утвърждение, а отговорът на въпроса „изискваше ли се MFA“ живее в журналите на доставчика, не в тези на защитната стена. Четенето на грешния журнал е най-честият начин да диагностицирате погрешно внедряване, което работи точно както е проектирано. Самата услуга също ограничава церемонията: FortiOS 7.6.3 премахва тунелния режим на SSL VPN в полза на IPsec, а уеб режимът продължава като Agentless VPN на поддържаните модели, така че церемония, доказана на една услуга, не е автоматично налична на друга.

Локална проверка: токени и кодове по имейл

Управляваните от FortiGate фактори се прикачват към обекта на потребителя. FortiToken или документирана интеграция на токен изисква регистрация, поддържаната церемония за проверка, лицензиране където е приложимо, и процедура за замяна. Кодът по имейл изисква работещ SMTP път и пощенска кутия, до която потребителят може да стигне преди тунелът да съществува, което е зависимост без нищо общо с криптографията и с всичко общо с това дали някой може да влезе.

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

Доставянето на имейл е част от наличността на удостоверяването. Пощенска кутия, достъпна само през VPN, създава цикъл, който не се разрешава за никого, а забавянето на доставка, валидността на кода и таймаутът за отдалечено удостоверяване са три отделни ограничения. Повишаването на едно не поправя недостъпна кутия и проект, който никога не е тествал цикъла, ще го открие при първото нулиране на парола след празник.

Изискванията за гаранция също принадлежат тук, преди избора на продукт. NIST SP 800-63B счита имейла за неприемлив за извънканално удостоверяване, така че внедряване, което твърди съответствие, не може да използва код по имейл като втори фактор, колкото и удобно да е. Наличието на функция в устройството не е твърдение, че функцията отговаря на даден стандарт.

RADIUS: шлюзът пита, бекендът решава

С RADIUS FortiGate изпраща идентификационните данни до бекенд, който притежава политиката за фактори. Обменът може да е просто приемане или отказ, или може да включва предизвикателство, на което клиентът трябва да отговори, което означава, че и VPN услугата, и клиентът трябва да поддържат тази форма на предизвикателство. Бекенд, който налага push одобрение, и клиент, който умее само да добавя шестцифрен код към парола, няма да се срещнат по средата.

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>

Тествайте бекенда независимо, преди да обвинявате тунела. Ако тестът authserver успее, а влизането през VPN не, разликата е в обработката на предизвикателството, а не в идентификационните данни, и дебъгът на демона за удостоверяване на шлюза е мястото, където това се вижда:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: браузърът напуска шлюза

В проект със SAML клиентът се пренасочва към доставчика на идентичност, удостоверява се там и се връща с утвърждение, което шлюзът проверява спрямо доверителна връзка и съпоставяне на групи. Шлюзът никога не вижда паролата или втория фактор, което е едновременно подобрение на сигурността и оперативно усложнение: отказът вече се случва в сесия на браузъра, която защитната стена не може да инспектира.

Приемането на утвърждение не доказва, че доставчикът е изисквал MFA за това влизане. Политика на доставчик, която прилага MFA към някои приложения, а към други не, ще даде точно влизането, което сте поискали, и нищо от гаранцията, която сте предполагали. Проверете политиката на доставчика за това конкретно приложение и проверете, че съпоставянето на груповите твърдения към групите на FortiGate все още съвпада след всяко преименуване от която и да е страна.

Поддръжката на клиента е важна тук повече отвсякъде другаде. Някои VPN клиенти обработват предаването към браузъра нативно, други отварят системния браузър, а клиенти без интерфейс или команден ред може изобщо да не завършат потока. Тествайте с клиента, който потребителите действително използват, на платформите, които действително използват, преди да публикувате профила.

Възстановяването е част от механизма

Всеки проект по-горе има зависимост, която може да се провали за един потребител наведнъж: недостъпна пощенска кутия, изгубен токен, бекенд, който отхвърля предизвикателство, заключен акаунт при доставчика на идентичност. Решете сега кой може да възстанови достъп, чрез коя поддържана процедура и с каква проверка на човека, който иска. Авариен локален администраторски акаунт, държан отделно от пътя на VPN, е контрола; а необясним обход само с парола е инцидент, който чака да бъде открит.

След това тествайте три влизания преди внедряване: нормалното, отхвърлен или изтекъл фактор и одобреното възстановяване на изгубен удостоверител. Запишете в кой журнал се появява всяко. Именно този запис превръща „MFA е включен“ в проект, който някой друг може да управлява.

Подобни статии