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

Гејтвејот, RADIUS backend-от или SAML провајдерот можат да го проверат факторот, и секој неуспева различно. Усогласете услуга, клиент и пат за враќање.

Секој FortiGate VPN MFA дизајн прво одговара на едно прашање: кој го проверува вториот фактор? Самиот гејтвеј може да го направи тоа со локален токен или код испратен по е-пошта, RADIUS backend може да го наложи и да врати предизвик, или SAML провајдер за идентитет може да ја преземе целата церемонија во прелистувач. Секој од нив произведува различен редослед на најава, различен потпис на неуспех и различна постапка за враќање, а копирањето на команден блок меѓу нив произведува конфигурација што изгледа веродостојно и не автентификува никого. Ова е статија за механизмот: што всушност прави секој дизајн при најава и каде се крши.

Церемонијата на најава одлучува кој го поседува факторот

Во првите два дизајна FortiGate е страната што се потпира. Ги собира акредитивите, одлучува дали е потребен втор фактор и го проверува локално или преку барање предизвик. Во третиот дизајн гејтвејот престанува да биде проверувач и станува реле: го пренасочува клиентот кон провајдерот за идентитет, прима тврдење и ја мапира потврдената идентичност на корисник и група. Во дизајнот со RADIUS тој е помеѓу нив и води размена на барање и одговор со backend што ја држи политиката.

Таа разлика одлучува какви докази можете да соберете. Кога гејтвејот проверува, неговиот сопствен дебаг излез ви кажува што се случило. Кога проверува провајдер за идентитет, гејтвејот знае само дека пристигнало тврдење, а одговорот на прашањето „дали MFA навистина беше потребен“ живее во логовите на провајдерот, не во логовите на firewall-от. Читањето погрешен лог е најчестиот начин погрешно да се дијагностицира распоредување што се однесува точно како што е дизајнирано. И самата услуга ја ограничува церемонијата: 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: гејтвејот прашува, backend-от одлучува

Со RADIUS, FortiGate ги испраќа акредитивите до backend што ја поседува политиката за фактори. Размената може да биде едноставно прифаќање или одбивање, или може да вклучи предизвик на кој клиентот треба да одговори, што значи дека и VPN услугата и клиентот мора да го поддржат тој облик на предизвик. Backend што наложува 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>

Тестирајте го backend-от независно пред да го обвините тунелот. Ако тестот authserver успее, а најавата преку VPN не, разликата е во ракувањето со предизвикот, а не во акредитивите, и дебагот на демонот за автентикација на гејтвејот е местото каде што тоа се гледа:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: прелистувачот го напушта гејтвејот

Во дизајн со SAML клиентот се пренасочува кон провајдерот за идентитет, се автентификува таму и се враќа со тврдење што гејтвејот го валидира против доверба и мапирање на групи. Гејтвејот никогаш не ја гледа лозинката или вториот фактор, што е истовремено безбедносно подобрување и оперативна компликација: неуспехот сега се случува во сесија на прелистувач што firewall-от не може да ја провери.

Прифаќањето на тврдење не докажува дека провајдерот барал MFA за таа најава. Политика на провајдер што применува MFA на некои апликации, а не на други, ќе го даде точно бараната најава и ништо од гаранцијата што ја претпоставивте. Проверете ја политиката на провајдерот за оваа конкретна апликација и проверете дали мапирањето на групните тврдења на FortiGate групите уште се совпаѓа по било какво преименување на која било страна.

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

Враќањето е дел од механизмот

Секој дизајн погоре има зависност што може да откаже за еден корисник во еден момент: недостапно сандаче, изгубен токен, backend што одбива предизвик, заклучен профил на провајдер за идентитет. Одлучете сега кој може да го врати пристапот, преку која поддржана постапка и со каква проверка на лицето што го бара. Итен локален администраторски профил што се држи одделно од патот на VPN е контрола; а необјаснет обид за заобиколување само со лозинка е инцидент што чека да биде откриен.

Потоа тестирајте три најави пред распоредувањето: нормалната, одбиен или истечен фактор и одобрено враќање на изгубен автентикатор. Забележете во кој лог се појавува секоја. Токму тој запис го претвора „MFA е вклучен“ во дизајн што некој друг може да го води.

Поврзани статии