फ़ील्ड डिवाइस, TLS और VPN: कौन-सी सीमा क्या सुरक्षित करती है

एक फ़ील्ड डिवाइस किसी सेवा से कनेक्शन खोलता है और डिज़ाइन का सवाल VPN और TLS के बीच चुनाव के रूप में आता है। यह ढाँचा ग़लत है, क्योंकि दोनों अलग-अलग काम करते हैं। TLS एप्लिकेशन के अंतिम बिंदु को प्रमाणित करता है और बातचीत की रक्षा करता है; जबकि VPN पहुँच को नियंत्रित करता है और साथियों के बीच पैकेट की रक्षा करता है। डिवाइस से बाहर की ओर कनेक्शन का अनुसरण करें और हर परत का अपना उत्तर है।

अगर आप यह नहीं बता सकते कि TLS कहाँ समाप्त होता है, तो आप यह भी नहीं बता सकते कि एप्लिकेशन वास्तव में किस पर भरोसा करता है।

पता लगाएँ कि TLS वास्तव में कहाँ समाप्त होता है

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

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

TLS दोनों दिशाओं में अनुरोध और प्रतिक्रियाएँ ले जाता है, इसलिए द्विदिश एप्लिकेशन को स्वभावत: TLS के बजाय VPN की ज़रूरत नहीं होती। उलटा भी सच है: परिनियोजन को उसी डिवाइस पर अन्य प्रोटोकॉल के लिए अब भी VPN चाहिए हो सकता है।

तय करें कि डिवाइस को क्या प्रमाणित करना है

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

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

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

हैंडशेक विफल होने पर बंद रहें

विफल हैंडशेक या विफल पहचान जाँच को चुपचाप मूल स्पष्ट-पाठ प्रोटोकॉल पर नहीं लौटना चाहिए। वही वापसी वह भेद्यता है जिसे TLS का काम बंद करना था। विफलता को डिवाइस ऑपरेटर और सेवा के लिए दृश्य बनाएँ, और संवेदनशील कार्यों के लिए सुरक्षित चैनल अनिवार्य करें। फिर एप्लिकेशन प्राधिकरण को तय करने दें कि प्रमाणित डिवाइस क्या कर सकता है।

कनेक्शन का जीवनकाल, फ़्रेमिंग, समय-सीमाएँ और पुन:प्रयास व्यवहार अनुबंध के हिस्से के रूप में परिभाषित करें। एन्क्रिप्शन बार-बार दिए गए आदेश को सुरक्षित नहीं बनाता, और अनिश्चित पिछले संचालन के बाद पुन:प्रयास को एप्लिकेशन स्तर का उत्तर चाहिए।

वापसी का नियम लिखें। “अगर हैंडशेक विफल होता है तो यह TLS के बिना फिर से जुड़ता है” एक डिज़ाइन निर्णय है, और यह स्पष्ट होना चाहिए।

VPN को केवल वही काम दें जो वह कर सकता है

VPN पहुँच को सीमित कर सकता है और अपने साथी तक पैकेट की रक्षा कर सकता है। TLS चुने गए अंतिम बिंदु के साथ एप्लिकेशन के संबंध की रक्षा करता है। उनके समाप्ति बिंदु अलग हो सकते हैं, और दोनों में से कोई भी अंतिम बिंदु के संग्रहीत डेटा या प्रशासनिक पहुँच को सुरक्षित नहीं करता।

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