दो लॉगिन जाँचें दो कारक नहीं हैं: VPN और RADIUS

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 सर्वर और निर्देशिका एक-दूसरे को दोष देंगे।

किसी भी प्लगइन या फ़र्मवेयर बदलाव के बाद चारों अस्वीकृतियाँ दोबारा चलाएँ। वे सस्ती हैं, और जिस नीति की वे रक्षा करती हैं वही हमलावर पहले जाँचता है।