FortiGate VPN MFA: жергілікті токен, RADIUS немесе SAML?

Шлюз, RADIUS бэкенді немесе SAML провайдері факторды тексере алады, және әрқайсысы әртүрлі сәтсіздікке ұшырайды. Қызметті, клиентті және қалпына келтіру жолын сәйкестендіріңіз.

Әрбір FortiGate VPN MFA жобасы алдымен бір сұраққа жауап береді: екінші факторды кім тексереді? Шлюздің өзі мұны жергілікті токенмен немесе электрондық поштамен жіберілген кодпен жасай алады, RADIUS бэкенді оны мәжбүрлеп, шақыруды қайтара алады, немесе SAML сәйкестік провайдері бүкіл рәсімді браузерде өз мойнына ала алады. Олардың әрқайсысы басқа кіру ретін, басқа сәтсіздік белгісін және басқа қалпына келтіру рәсімін тудырады, ал олардың арасында командалар блогын көшіру сенімді болып көрінетін, бірақ ешкімді аутентификацияламайтын конфигурация жасайды. Бұл механизм туралы мақала: әрбір жоба кіру кезінде шын мәнінде не істейді және қай жерде сынады.

Кіру рәсімі фактордың кімге тиесілі екенін анықтайды

Алғашқы екі жобада FortiGate сенетін тарап. Ол тіркелгі деректерін жинайды, екінші фактор қажет пе, соны шешеді және оны жергілікті түрде немесе шақыру арқылы тексереді. Үшінші жобада шлюз тексеруші болуды тоқтатып, релеге айналады: клиентті сәйкестік провайдеріне бағыттайды, дәйектемені қабылдайды және расталған сәйкестікті пайдаланушы мен топқа сәйкестендіреді. RADIUS жобасында ол екеуінің ортасында тұрып, саясатты ұстайтын бэкендпен сұраныс-жауап алмасуын жүргізеді.

Бұл айырмашылық қандай дәлелдер жинай алатыныңызды анықтайды. Шлюз тексергенде, оның өз жөндеу шығысы не болғанын айтады. Сәйкестік провайдері тексергенде, шлюз тек дәйектеменің келгенін біледі, ал «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: шлюз сұрайды, бэкенд шешеді

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 жобасында клиент сәйкестік провайдеріне бағытталады, сонда аутентификацияланады және шлюз сенім қатынасы мен топ сәйкестендіруіне қарсы тексеретін дәйектемемен оралады. Шлюз құпия сөзді де, екінші факторды да ешқашан көрмейді, бұл бір уақытта қауіпсіздік жақсартуы және операциялық қиындық: сәтсіздік енді firewall тексере алмайтын браузер сессиясында болады.

Дәйектемені қабылдау провайдердің сол кіру үшін MFA талап еткенін дәлелдемейді. MFA-ны кейбір қолданбаларға қолданып, басқаларына қолданбайтын провайдер саясаты дәл сіз сұраған кіруді береді және сіз болжаған кепілдіктің ешбірін бермейді. Провайдердің саясатын осы нақты қолданба үшін тексеріңіз және топ мәлімдемелерінің FortiGate топтарына сәйкестендірілуі кез келген тараптағы кез келген атау өзгерісінен кейін де сәйкес келетінін тексеріңіз.

Клиенттің қолдауы мұнда кез келген жерден маңыздырақ. Кейбір VPN клиенттері браузерге беруді өздігінен өңдейді, кейбіреулері жүйелік браузерді ашады, ал интерфейсіз немесе командалық жол клиенттері ағынды мүлде аяқтамауы мүмкін. Профильді жарияламас бұрын пайдаланушылар шын мәнінде іске қосатын клиентпен және шын мәнінде пайдаланатын платформаларда сынаңыз.

Қалпына келтіру механизмнің бөлігі

Жоғарыдағы әрбір жобаның бір уақытта бір пайдаланушы үшін сәтсіз болуы мүмкін тәуелділігі бар: жете алмайтын пошта жәшігі, жоғалған токен, шақыруды қабылдамайтын бэкенд, құлыпталған сәйкестік провайдерінің тіркелгісі. Енді кімнің қолжетімділікті қалпына келтіре алатынын, қандай қолдау көрсетілетін рәсіммен және сұраушы адамды қалай тексеретінін шешіңіз. VPN жолынан бөлек ұсталатын төтенше жергілікті әкімші тіркелгісі — бақылау; ал түсіндірілмеген тек-құпиясөзді айналып өту — ашылуын күтіп тұрған оқиға.

Содан кейін енгізу алдында үш кіруді сынаңыз: қалыпты, қабылданбаған немесе мерзімі өткен фактор, және мақұлданған жоғалған аутентификаторды қалпына келтіру. Әрқайсысы қай журналда көрінетінін жазып алыңыз. Дәл сол жазба «MFA қосулы» дегенді басқа біреу басқара алатын жобаға айналдырады.

Қатысты мақалалар