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