FortiGate VPN MFA: локални токен, 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 је укључен“ у дизајн којим неко други може да управља.