सर्वर कुंजियों और उपयोगकर्ता क्रेडेंशियल को अलग मालिकों की आवश्यकता क्यों है

जो कुंजी साबित करती है कि आपका गेटवे स्वयं है और जो क्रेडेंशियल कहता है कि एक व्यक्ति जुड़ सकता है, दोनों रहस्य हैं, और समानता यहीं खत्म होती है। एक हर क्लाइंट के सामने एक सेवा की पहचान बताता है; दूसरा उस सेवा के सामने एक उपयोगकर्ता की पहचान बताता है। इन्हें मिलाने से सेटअप में एक कदम बचता है और किसी घटना के दौरान एक दोपहर खर्च होती है, क्योंकि दोनों की वसूली एक ही क्रिया नहीं है। अलगाव बनाना उबाऊ है और छोड़ देना यादगार है।

दो रहस्य, दो अलग मालिक

गेटवे एक निजी कुंजी या प्रमाणपत्र रखता है जिसका एकमात्र काम हैंडशेक के दौरान अपनी पहचान साबित करना है। क्लाइंट को इसे सत्यापित करने के लिए मेल खाती सार्वजनिक सामग्री चाहिए, और उन्हें निजी आधे हिस्से की कभी आवश्यकता नहीं होती। यही असमानता हर उपयोगकर्ता को सर्वर का रूप धारण करने की क्षमता दिए बिना सर्वर प्रमाणीकरण को संभव बनाती है।

उपयोगकर्ता की सामग्री दूसरी दिशा में जाती है। क्लाइंट की निजी कुंजी, क्लाइंट प्रमाणपत्र या पासवर्ड दर्शाते हैं कि इस विशेष व्यक्ति या डिवाइस को पहुंच दी गई है। अपेक्षा है कि इसे बांटा जाएगा, डिवाइसों के बीच प्रतिलिपि बनाया जाएगा और अंततः रद्द किया जाएगा।

WireGuard अलगाव को स्पष्ट करता है क्योंकि हर भागीदार के पास कुंजी-युग्म होता है: सर्वर की निजी कुंजी सर्वर पर रहती है, और उपयोगकर्ता को दी गई कॉन्फ़िगरेशन फ़ाइल में उसकी अपनी निजी कुंजी तथा सर्वर की सार्वजनिक कुंजी होती है। सर्वर की निजी कुंजी वाली प्रोफ़ाइल कोई शॉर्टकट नहीं है, वह फ़ाइल साझा होने का इंतज़ार करता एक समझौता है।

अलगाव तय करने वाले तीन प्रश्न

पूछें कि रहस्य कौन पढ़ सके, लीक होने पर हमलावर क्या कर सकेगा, और समाधान एक बार रद्द करना है या सेवा का पुनर्निर्माण।

यदि कोई उपयोगकर्ता इसे पढ़ सकता है और यह गेटवे की पहचान साबित करता है, तो दूसरे प्रश्न का उत्तर है कि हमलावर हर क्लाइंट के सामने आपके सर्वर का रूप धारण कर सकता है — सबसे बुरा परिणाम, क्योंकि क्लाइंट उस पहचान पर भरोसा करने के लिए ही बने हैं। यदि यह केवल एक उपयोगकर्ता को साबित करता है, तो लीक उस उपयोगकर्ता को एक साथी तक पहुंच देता है, और रद्द करना एक नियमित क्रिया है। यदि यह प्रमाणपत्र प्राधिकरण की कुंजी है, तो लीक दोनों से बुरा है, क्योंकि हमलावर ऐसी पहचान बना सकता है जिन पर हर अंतिम बिंदु भरोसा करता है।

ये तीन उत्तर संग्रहण नियम देते हैं: CA कुंजी ऑफ़लाइन या तिजोरी में रहती है, गेटवे कुंजी गेटवे पर रहती है, और उपयोगकर्ता कुंजियाँ उपयोगकर्ताओं के पास रहती हैं। सुविधा के लिए तीनों को एक ही निर्देशिका में रखने वाला कोई भी विन्यास निर्णय को दुर्घटना में बदल देता है।

क्लाइंट को वास्तव में क्या चाहिए

क्लाइंट को सार्वजनिक प्रमाणपत्र या सार्वजनिक साथी कुंजी, जिस CA सामग्री या फ़िंगरप्रिंट पर भरोसा करना है, अपनी निजी कुंजी और अंतिम बिंदु के विवरण चाहिए। उस सूची में गेटवे की निजी पहचान का कुछ भी नहीं है।

दस्तावेज़ीकरण वही जगह है जहाँ यह लीक होता है। जो मार्गदर्शिका कहती है कि सर्वर निर्देशिका की प्रतिलिपि बनाएँ और जो ज़रूरी न हो उसे हटा दें, वह पहले ही गलत मॉडल सिखा चुकी है, क्योंकि हटाने के चरण के बाद बची फ़ाइल की जाँच शायद ही कोई करता है।

गेटवे को छुए बिना एक उपयोगकर्ता रद्द करें

क्योंकि उपयोगकर्ता पहचान अलग से जारी होती हैं, उन्हें अलग से वापस लिया जा सकता है। प्रमाणपत्र आधारित परिनियोजन क्लाइंट प्रमाणपत्र रद्द करता है और अद्यतन निरसन सूची प्रकाशित करता है; WireGuard परिनियोजन सर्वर कॉन्फ़िगरेशन से साथी प्रविष्टि हटाता है। इनमें से कोई भी क्रिया गेटवे की अपनी कुंजी नहीं बदलती।

जारी करने का रिकॉर्ड रखें, वरना आपको पता नहीं चलेगा कि कौन सी पहचान वापस लेनी है। एक स्प्रेडशीट पर्याप्त है, बशर्ते वह व्यक्ति, डिवाइस, क्रमांक या सार्वजनिक कुंजी और तिथि बताए, और बशर्ते उसे बनाने वाले व्यक्ति के जाने के बाद कोई उसकी देखरेख करे।

नीचे दिए आदेश एक क्लाइंट प्रमाणपत्र की जाँच करते हैं और फिर OpenSSL शैली के प्राधिकरण के माध्यम से उसे रद्द करते हैं, जो वही प्रवाह है जिसे easy-rsa लपेटता है:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

नई सूची वहीं प्रकाशित करें जहाँ क्लाइंट उसे जाँचते हैं, वरना निरसन किसी फ़ाइल में एक टिप्पणी है जो कुछ नहीं बदलती। यदि आपका गेटवे निरसन सूची देखे बिना क्लाइंट प्रमाणपत्र स्वीकार करता है, तो निरसन के काम करने का संकेत देने के बजाय यह स्पष्ट कहें।

बैकअप को रहस्यों जितना अलग रखें

पुनर्निर्माण संग्रह में गेटवे कुंजी और CA सामग्री वैध रूप से होती है, क्योंकि उनके बिना पुनर्स्थापन सेवा को फिर से नहीं बना सकता। क्लाइंट सेटअप पैकेज में यह नहीं होना चाहिए, और दोनों को साथ संग्रहित नहीं करना चाहिए। हर संग्रह को इस आधार पर लेबल करें कि कौन इसे रख सकता है, बनने की तिथि के आधार पर नहीं। थका हुआ प्रशासक रात दो बजे यही लेबल पढ़ता है।

यह भेद यह भी तय करता है कि कौन हर एक को पुनः प्राप्त कर सकता है। गेटवे का प्रशासन, उपयोगकर्ता पहचान जारी करना और बैकअप पढ़ना तीन अलग शक्तियाँ हैं, और जिसे एक चाहिए उसे स्वतः बाकी नहीं चाहिए। उन अनुमतियों को लिखें, फिर उन्हें इस बात से जाँचें कि आपका संग्रहण वास्तव में क्या अनुमति देता है, क्योंकि निर्देशिका विरासत चुपचाप नीति से अधिक दे देती है।