Ар бир 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 күйүк» дегенди башка бирөө башкара ала турган долбоорго айландырат.

Тектеш макалалар