VPN पासवर्ड बनाम क्लाइंट सर्टिफिकेट: कौन तेज़ी से रिकवर होता है
पासवर्ड और सर्टिफिकेट अलग-अलग चीज़ें साबित करते हैं और अलग-अलग जगहों पर विफल होते हैं। उन्हें मिलाने से पहले जारी करना, समाप्ति और निरस्तीकरण की तुलना करें।
एक परिनियोजन उपयोगकर्ता नाम और पासवर्ड मांगता है, दूसरा क्लाइंट सर्टिफिकेट, और तीसरा दोनों। यह चुनाव लॉगिन प्रॉम्प्ट से कहीं अधिक बदलता है: यह तय करता है कि क्रेडेंशियल कैसे जारी होते हैं, कैसे समाप्त होते हैं, रात 2 बजे रिकवरी कैसी दिखती है और कौन ठीक एक डिवाइस के लिए पहुँच रद्द कर सकता है। डायलॉग बॉक्स नहीं, परिचालन जीवनचक्र की तुलना करें।
पासवर्ड एक खाता रहस्य है जिसे प्रमाणीकरण प्रक्रिया द्वारा मान्य किया जाता है, जबकि सर्टिफिकेट एक पहचान और उसकी निजी कुंजी पर अधिकार का प्रमाण है। ये अलग-अलग विफलता वाले अलग ऑब्जेक्ट हैं।
दो अलग प्रमाण, दो अलग प्रॉम्प्ट
पासवर्ड साझा रहस्य के ज्ञान को साबित करता है, इसलिए सर्वर हैश की तुलना करता है और खाता प्रणाली जीवनचक्र की मालिक है। सर्टिफिकेट निजी कुंजी पर अधिकार साबित करता है, और सर्वर अपने विश्वसनीय CA तक हस्ताक्षर श्रृंखला सत्यापित करता है। दूसरा व्यक्ति के बजाय डिवाइस की पहचान कर सकता है, इसलिए परिनियोजन अक्सर प्रति लैपटॉप एक जारी करते हैं। कुंजी फ़ाइल की रक्षा करने वाला पासफ़्रेज़ फिर तीसरी चीज़ है: यह फ़ाइल की आराम की स्थिति में रक्षा करता है और VPN खाता पासवर्ड नहीं है।
हर संयोजन में सर्वर सत्यापन आवश्यक रहता है। जिस एंडपॉइंट की पहचान आपने जाँचना बंद कर दिया है, उसे भेजे गए वैध क्रेडेंशियल अब भी उत्तर देने वाले को सौंपे गए क्रेडेंशियल ही हैं, इसलिए सर्वर-सर्टिफिकेट जाँच समस्या निवारण के चरण में नहीं, मूल प्रोफ़ाइल में होनी चाहिए।
जारी करना, समाप्ति और निरस्तीकरण ही असली लागत हैं
पासवर्ड जारी करना सस्ता और सहायता देना महंगा है: रीसेट, नीति, पुनः उपयोग और हेल्पडेस्क कतार। सर्टिफिकेट उस लागत को आगे लाते हैं, जहाँ CA, हस्ताक्षर प्रक्रिया और वितरण चैनल चाहिए, और फिर एक समाप्ति कैलेंडर जोड़ते हैं जिसे कोई याद नहीं रखता। दोनों को नियोजित निरस्तीकरण चाहिए। निरस्त सर्टिफिकेट को ऐसी CRL चाहिए जिसे हर सर्वर वास्तव में पढ़े, और निष्क्रिय खाते को प्रमाणीकरण बैकएंड से अगली सिंक पर नहीं, अगले कनेक्शन पर ही इनकार चाहिए।
कोई भी तंत्र केवल मौजूद होने से सुरक्षित नहीं होता। सवाल यह है कि टीम कौन-सा जीवनचक्र लगातार चला सकती है।
डिवाइस खोने पर क्या टूटता है
खोए हुए लैपटॉप के लिए, उस डिवाइस ने जो प्राधिकरण वास्तव में इस्तेमाल किया था उसे हटाएँ। पासवर्ड रीसेट उसका सर्टिफिकेट निरस्त नहीं करता, और नया सर्टिफिकेट जारी करने से असंबंधित खाते का पासवर्ड नहीं बदलता। प्रति-डिवाइस अलग पहचान लक्षित हटाना संभव बनाती है, जबकि साझा क्रेडेंशियल का अर्थ है कि एक डिवाइस हटाने से कई प्रभावित होते हैं। हर तंत्र के लिए रिकवरी प्रक्रिया ज़रूरत से पहले लिखें, जिसमें यह भी शामिल है कि कार्यालय समय के बाहर कौन प्रतिस्थापन सर्टिफिकेट पर हस्ताक्षर कर सकता है।
निरस्तीकरण पथ का अभ्यास करें, उसे मान न लें: एक परीक्षण पहचान निरस्त करें, पुष्टि करें कि सर्वर नए कनेक्शन पर उसे अस्वीकार करता है, फिर उसे बहाल करें। कभी अभ्यास न किया गया निरस्तीकरण पथ ठीक तभी विफल होता है जब उसकी ज़रूरत होती है।
काम दोगुना किए बिना दोनों चलाना
कई परिनियोजन जानबूझकर दोनों को जोड़ते हैं: डिवाइस के लिए सर्टिफिकेट और व्यक्ति के लिए खाता क्रेडेंशियल, ताकि चोरी हुआ लैपटॉप पर्याप्त न हो और लीक हुआ पासवर्ड भी पर्याप्त न हो। यह संयोजन तभी फ़ायदेमंद है जब दोनों जीवनचक्र अलग रहें और दोनों स्वचालित हों। अन्यथा हेल्पडेस्क दो कतारें चलाता है और सुरक्षा लाभ सैद्धांतिक रहता है।
वह विधि चुनें जिसे सेवा के क्लाइंट और प्रबंधन उपकरण वास्तव में समर्थन देते हैं। बेमेल प्रोफ़ाइल को कनेक्ट कराने के लिए सत्यापन कमज़ोर करना पूरा उद्देश्य उलट देता है, और कनेक्ट होने तक संपादित प्रोफ़ाइल अक्सर वह होती है जो अब उसकी जाँच नहीं करती जिसके लिए इसे बनाया गया था।
नोट करें कि हर परिनियोजन कौन-सा प्रमाण मांगता है और हर एक कैसे निरस्त होता है। अगली घटना ठीक यही मांगेगी।