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 үйлчилгээ болон клиент хоёулаа сорилтын тэр хэлбэрийг дэмжих ёстой гэсэн үг. Push зөвшөөрөл шаарддаг backend болон нууц үгэнд зургаан оронтой код хавсаргахаас өөр юу ч мэдэхгүй клиент дунд уулзахгүй.

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 идэвхтэй» гэдгийг өөр хэн нэгэн ажиллуулж чадах загвар болгон хувиргадаг.

Холбоотой нийтлэлүүд