فحصان لتسجيل الدخول ليسا عاملين اثنين: VPN وRADIUS
فحص حساب محلي مع RADIUS هما تحققان، لا نوعان من العوامل. قارن سياسات AND وOR والرجوع، ثم اختبر التوليفة.
إضافة خلفية مصادقة ثانية إلى بوابة VPN تبدو كإضافة عامل ثانٍ. لكنها تضيف عادة فحصًا ثانيًا، وهو كائن مختلف بأوضاع فشل مختلفة. وما إذا كان يجب أن ينجح الاثنان، وما يثبته كل منهما، وما يحدث عندما يتعذر أحدهما، ثلاثة قرارات منفصلة. وإن أخطأت فيها تصبح البوابة أكثر صرامة في العرض وأضعف أثناء الانقطاع.
ما تثبته الخلفية الثانية فعليًا
البحث في حساب محلي يثبت أن اسمًا موجود في قاعدة بيانات وأن كلمة مرور طابقته. وتبادل RADIUS يثبت أن خادم RADIUS أعاد Access-Accept للسمات التي تلقاها. لا يذكر أي من البيانين نوع عامل، لأن كليهما يتحقق من المعرفة. وتحسب إرشادات NIST للهوية الرقمية أنواع العوامل المميزة ومصادقتها، لا الخوادم أو المطالبات.
هناك تصميم مشروع يشارك فيه النظامان معًا. يمكن لخدمة مركزية أن تصادق على الشخص بينما تتحقق البوابة باستقلال مما إذا كان ذلك الحساب مخولًا لهذا النفق. وهذا تفويض يسير إلى جانب المصادقة، ووصفه بأنه عاملان يخلط بين فحص سياسة وإثبات حيازة.
يمكن لـ RADIUS أن يحمل عاملًا ثانيًا حقيقيًا عندما يتقدم شيئًا يتحقق من أحدها، مثل موافقة دفع أو رمز عتاد. ولا يخبرك الظرف أي مصادقات أظهرها المستخدم، فاقرأ سياسة الخلفية بدلًا من تسمية البوابة.
AND وOR والرجوع منتجات مختلفة
قبل مقارنة التنفيذات، حدد ما يعنيه كلاهما في متطلبك. سياسة AND تشترط نجاح كل فحص مسمى، وسياسة OR تقبل أي فحص ينجح، والرجوع يجرب الثاني فقط في ظروف فشل معلنة. وتلك الثلاثة تتصرف تصرفًا متعاكسًا أثناء الانقطاع، وواحدة فقط منها عادة هي ما قصده المراجع.
إضافة مدخلين للخلفية إلى شاشة إعدادات لا تكشف أي سياسة ينفذها المنتج. بعض البوابات تسلسل الإضافات بالترتيب وتتوقف عند أول رفض، وهذا AND فقط عندما تكون كل إضافة مطلوبة. وغيرها يعامل الحساب المحلي كتجاوز، فيحول انقطاعًا مركزيًا إلى تحايل. والجواب الموثوق اختبار سلبي موثق لكل مسار، يُجرى على البناء الذي تنشره.
الرجوع يستحق أكبر قدر من الشك، لأنه موجود ليبقى يعمل عندما يتعطل شيء. والرجوع الذي يقبل كلمة مرور محلية كلما تعذر الوصول إلى RADIUS قد حول سياسة مركزية إلى باب ثانٍ أضعف.
الفحص المزدوج في OpenVPN حالة ملموسة
يتطلب OpenVPN المجتمعي 2.6 شهادة عميل وسكربت auth-user-pass-verify المهيأ معًا عندما يكون كلاهما مفعّلًا. هذا AND موثق بين التحقق من الشهادة وسكربت بيانات الاعتماد، وهو فحصان حقيقيان. لكنه ليس تلقائيًا نوعين من العوامل، لأن السكربت قد يتحقق فقط من كلمة مرور.
التوليفة تترك أيضًا سؤال الاقتران مفتوحًا. الشهادة عادة تحدد جهازًا بينما تحدد بيانات الاعتماد شخصًا، ولا شيء في التدفق الافتراضي يشترط أن يشير الاثنان إلى نفس الأصيل. قرر أي الأزواج مسموح، ثم افرض تلك الخريطة داخل سكربت التحقق أو في خطوة تفويض لاحقة.
وضع الشهادة فقط فحص واحد، مدعوم بمفتاح قد يكون محميًا برقم PIN أو لا يكون. ورقم PIN يحول بيانات الاعتماد نفسها إلى معرفة زائد حيازة فقط إذا كان المفتاح لا يمكن استخدامه بدونه. وترك ذلك المفتاح غير مشفر على القرص يخفض الجزء الثاني إلى إذن ملف.
مورّدو الأجهزة يبنون سباكة خاصة بهم، غالبًا وحدة PAM أو إضافة RADIUS خلف وحدة تحكم ويب. وسلوك المجتمع مرجع لشكل الفحوص المزدوجة، لا وصف لكيفية دمج الجهاز لها.
افحص التوليفة على بوابتك
اقرأ الإعدادات قبل الوثوق بملخص وحدة التحكم. الأسطر التي تحدد السياسة هي وضع الشهادة وسكربت بيانات الاعتماد وترتيب الإضافات.
grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123
يكشف grep ما إذا كانت الشهادة مطلوبة وأي سكربت يعمل بعدها، والترتيب أهم مما توحي به الأسماء. ويظهر تفريغ الشهادة الهوية التي ستراها البوابة، بما في ذلك الـ CN والرقم التسلسلي اللذين تحتاجهما لخريطة الاقتران. واختبار RADIUS هو الحالة السلبية: كلمة مرور خاطئة يجب أن تنتج Access-Reject، وصحيحة Access-Accept. وإذا كانت بيانات اعتماد مرفوضة تنتج جلسة بعد، فالسكربت ليس على مسار المصادقة إطلاقًا.
ثم جرّب حالة الانقطاع على نسخة مختبرية: أوقف الخلفية المطلوبة واتصل ببيانات اعتماد صحيحة. النتيجة المتوقعة رفض، وأي شيء آخر هو سياسة الرجوع التي لم يوثقها أحد.
اكتب المتطلب كحالات سلبية
المتطلب القابل للاستخدام يسمي الأدلة والحسابات المسموح لها بتقديمها والنتيجة عند غياب مدقق. ويذكر أيضًا الاقتران المسموح بين هوية الجهاز وهوية الشخص. وهذا أدق من أسماء المنتجات على أمر الشراء، ويمكن اختباره.
يجب أن تشمل القبول أربعة رفضات: حساب محلي غير مؤهل، ودليل مطلوب مفقود، وعامل ثانٍ غير صالح، وخلفية مطلوبة غير قابلة للوصول. وكل رفض يحتاج سطر سجل يميزه عن الآخرين، وإلا افتتح الحادث التالي بالتخمين. وسجل أي مكوّن اتخذ كل قرار، لأن البوابة وخادم RADIUS والدليل سيلوم كل منها الآخرين.
أعد تشغيل الرفضات الأربعة بعد أي تغيير في الإضافة أو البرنامج الثابت. فهي رخيصة، والسياسة التي تحميها هي الجزء الذي يفحصه المهاجم أولًا.