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 والعميل يجب أن يدعما شكل التحدي ذلك. وخلفية تفرض موافقة دفعية وعميل لا يعرف إلا إلحاق كود من ستة أرقام بكلمة المرور لن يلتقيا في المنتصف.

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 مفعّل» إلى تصميم يستطيع شخص آخر تشغيله.