FortiGate VPN MFA: mahalliy token, RADIUS yoki SAML?

Har bir FortiGate VPN MFA dizayni birinchi navbatda bitta savolga javob beradi: ikkinchi omilni kim tasdiqlaydi? Shlyuzning o‘zi buni mahalliy token yoki elektron pochta orqali yuborilgan kod bilan qila oladi, RADIUS backend uni majburlab, qaytarib chaqiriq berishi mumkin, yoki SAML identifikatsiya provayderi butun marosimni brauzerda o‘z zimmasiga olishi mumkin. Ularning har biri boshqacha kirish ketma-ketligi, boshqacha nosozlik belgisi va boshqacha tiklash tartibini keltirib chiqaradi, ular orasida buyruq blokini nusxalash esa ishonchli ko‘rinadigan, ammo hech kimni tasdiqlamaydigan konfiguratsiyani hosil qiladi. Bu mexanizm haqidagi maqola: har bir dizayn kirish paytida aslida nima qiladi va qayerda buziladi.

Kirish marosimi omil kimga tegishli ekanini hal qiladi

Birinchi ikki dizaynda FortiGate tayanch tomon hisoblanadi. U hisob ma’lumotlarini yig‘adi, ikkinchi omil talab qilinishini hal qiladi va uni mahalliy ravishda yoki chaqiriq orqali tasdiqlaydi. Uchinchi dizaynda shlyuz tekshiruvchi bo‘lishni to‘xtatib, relega aylanadi: u mijozni identifikatsiya provayderiga yo‘naltiradi, da’vo oladi va da’vo qilingan identifikatsiyani foydalanuvchi va guruhga bog‘laydi. RADIUS dizaynida u o‘rtada bo‘lib, siyosatni saqlovchi backend bilan so‘rov-javob almashinuvini boshqaradi.

Aynan shu farq qanday dalil to‘plashingiz mumkinligini hal qiladi. Shlyuz tekshirganda uning o‘z debug natijasi nima bo‘lganini aytadi. Identifikatsiya provayderi tekshirganda shlyuz faqat da’vo kelganini biladi va «MFA haqiqatan talab qilindimi» degan javob fayrvolning emas, provayderning jurnallarida bo‘ladi. Noto‘g‘ri jurnalni o‘qish — aynan dizayndagidek ishlayotgan joriy etishni noto‘g‘ri tashxislashning eng keng tarqalgan usuli. Xizmatning o‘zi ham marosimni chegaralaydi: FortiOS 7.6.3 SSL VPN tunnel rejimini olib tashlaydi va IPsecni afzal ko‘radi, veb-rejim esa qo‘llab-quvvatlanadigan modellarda Agentless VPN sifatida davom etadi, shuning uchun bitta xizmatda isbotlangan marosim avtomatik ravishda boshqasida mavjud emas.

Mahalliy tekshirish: tokenlar va elektron pochta kodlari

FortiGate boshqaradigan omillar foydalanuvchi obyektiga bog‘lanadi. FortiToken yoki hujjatlashtirilgan token integratsiyasi ro‘yxatdan o‘tish, qo‘llab-quvvatlanadigan tekshirish marosimi, tegishli bo‘lsa litsenziya va almashtirish tartibini talab qiladi. Elektron pochta orqali yuborilgan kod ishlaydigan SMTP yo‘lini va foydalanuvchi tunnel paydo bo‘lishidan oldin yeta oladigan pochta qutisini talab qiladi, bu kriptografiyaga umuman aloqasi bo‘lmagan, balki kimdir kira olishiga bog‘liq bog‘liqlikdir.

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

Elektron pochta yetkazib berish autentifikatsiya mavjudligining bir qismidir. Faqat VPN orqali yetib boriladigan pochta qutisi hech kim uchun o‘z-o‘zidan hal bo‘lmaydigan halqa yaratadi, yetkazib berish kechikishi, kodning amal qilish muddati va masofaviy autentifikatsiya taymauti uchta alohida cheklovdir. Birini oshirish yetib bo‘lmaydigan pochta qutisini tuzatmaydi va bu halqani hech qachon sinab ko‘rmagan dizayn uni bayramdan keyingi birinchi parol tiklashda topadi.

Ishonch talablari ham shu yerda, mahsulot tanlovidan oldin. NIST SP 800-63B elektron pochtani tashqi kanal autentifikatsiyasi uchun qabul qilinmas deb hisoblaydi, shuning uchun muvofiqlik da’vo qilayotgan joriy etish qanchalik qulay bo‘lishidan qat’i nazar, elektron pochta kodini ikkinchi omil sifatida ishlata olmaydi. Qurilmada funksiyaning mavjudligi bu funksiya berilgan standartni qanoatlantiradi degani emas.

RADIUS: shlyuz so‘raydi, backend hal qiladi

RADIUS bilan FortiGate hisob ma’lumotlarini omil siyosatiga ega backendga yuboradi. Almashinuv oddiy qabul yoki rad bo‘lishi mumkin, yoki mijoz javob berishi kerak bo‘lgan chaqiriqni o‘z ichiga olishi mumkin, ya’ni VPN xizmati ham, mijoz ham bu chaqiriq shaklini qo‘llab-quvvatlashi kerak. Push tasdiqlashni majburlovchi backend va parolga olti xonali kodni qo‘shishni biladigan mijoz o‘rtada uchrashmaydi.

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>

Tunnelni ayblashdan oldin backendni alohida sinab ko‘ring. Agar authserver testi muvaffaqiyatli bo‘lib, VPN kirish bo‘lmasa, farq hisob ma’lumotlarida emas, chaqiriqni qayta ishlashda, va buni shlyuzning autentifikatsiya demoni debugi ko‘rsatadi:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: brauzer shlyuzdan chiqib ketadi

SAML dizaynida mijoz identifikatsiya provayderiga yo‘naltiriladi, u yerda autentifikatsiyadan o‘tadi va shlyuz ishonch munosabati va guruh xaritalash bo‘yicha tekshiradigan da’vo bilan qaytadi. Shlyuz parolni ham, ikkinchi omilni ham hech qachon ko‘rmaydi, bu bir vaqtda xavfsizlik yaxshilanishi va operatsion murakkablik: nosozlik endi fayrvol ko‘ra olmaydigan brauzer sessiyasida sodir bo‘ladi.

Da’voni qabul qilish provayder bu kirish uchun MFA talab qilganini isbotlamaydi. Ba’zi ilovalarga MFA qo‘llab, boshqalarga qo‘llamaydigan provayder siyosati siz so‘ragan kirishni beradi, lekin siz taxmin qilgan ishonchni bermaydi. Ushbu aniq ilova uchun provayder siyosatini tekshiring va FortiGate guruhlariga xaritalanadigan guruh da’volari ikki tomondan birida nom o‘zgargandan keyin ham mos kelishini tekshiring.

Mijoz qo‘llab-quvvatlashi bu yerda hamma joydan muhimroq. Ba’zi VPN mijozlari brauzer topshirig‘ini o‘zi bajaradi, ba’zilari tizim brauzerini ochadi, va boshsiz yoki buyruq qatori mijozlari bu jarayonni umuman tugata olmasligi mumkin. Profilni e’lon qilishdan oldin foydalanuvchilar haqiqatan ishlatadigan mijoz bilan va ular haqiqatan ishlatadigan platformalarda sinab ko‘ring.

Tiklash mexanizmning bir qismidir

Yuqoridagi har bir dizaynda bir vaqtda bitta foydalanuvchi uchun ishlamay qolishi mumkin bo‘lgan bog‘liqlik bor: yetib bo‘lmaydigan pochta qutisi, yo‘qolgan token, chaqiriqni rad etuvchi backend, qulflangan identifikatsiya provayderi hisobi. Hozir kim kirishni tiklashi mumkinligini, qaysi qo‘llab-quvvatlanadigan tartib orqali va so‘rayotgan shaxsni qanday tekshirish bilan hal qiling. VPN yo‘lidan alohida saqlanadigan favqulodda mahalliy administrator hisobi nazoratdir; tushuntirilmagan faqat parolga asoslangan chetlab o‘tish esa fosh etilishini kutayotgan hodisadir.

So‘ng joriy etishdan oldin uchta kirishni sinab ko‘ring: oddiy, rad etilgan yoki muddati o‘tgan omil, va tasdiqlangan yo‘qolgan autentifikator tiklash. Har biri qaysi jurnalda ko‘rinishini yozib qo‘ying. Aynan shu yozuv «MFA yoqilgan» degan gapni boshqa odam boshqara oladigan dizaynga aylantiradi.