फिल्ड उपकरण, TLS र VPN: कुन सीमाले के सुरक्षित गर्छ
फिल्ड उपकरणलाई प्रमाणित अनुप्रयोग च्यानल चाहिन्छ, केवल सञ्जाल पहुँच होइन। TLS कहाँ सकिन्छ पहिचान गर्नुहोस् र असफल हुँदा के हुन्छ निर्णय गर्नुहोस्।
फिल्ड उपकरणले सेवासँग जडान खोल्छ र डिजाइनको प्रश्न VPN र TLS बीचको छनोटका रूपमा आउँछ। यो ढाँचा गलत छ, किनकि दुवैले फरक काम गर्छन्। TLS ले अनुप्रयोगको अन्त्य बिन्दु प्रमाणित गर्छ र कुराकानी सुरक्षित गर्छ; भने VPN ले पहुँच नियन्त्रित गर्छ र सहकर्मीहरूबीच प्याकेट सुरक्षित गर्छ. उपकरणबाट बाहिरतिर जडान पछ्याउनुहोस् र प्रत्येक तहको आफ्नै उत्तर छ।
TLS कहाँ सकिन्छ भन्न सक्नुहुन्न भने अनुप्रयोगले वास्तवमा के विश्वास गर्छ भन्न पनि सक्नुहुन्न।
TLS वास्तवमा कहाँ सकिन्छ पत्ता लगाउनुहोस्
उपकरणको अनुप्रयोगबाट सुरु गर्नुहोस् र ह्यान्डशेक पूरा गर्ने प्रक्रियासम्म जडान पछ्याउनुहोस्। यदि प्रोक्सीले मेनफ्रेम अघि TLS सक्छ भने सुरक्षित मार्ग प्रोक्सीमै सकिन्छ। बाँकी चरणलाई आफ्नै दस्तावेजीकृत सुरक्षा चाहिन्छ।
अनुमानका आधारमा यसलाई छेउदेखि छेउसम्म भन्नु नै डिजाइन समीक्षाले खाडल स्वीकृत गर्ने तरिका हो। अन्त्य बिन्दु र विश्वासको आधार एउटै आकृतिमा कोर्नुहोस्।
TLS ले दुवै दिशामा अनुरोध र प्रतिक्रिया बोक्छ, त्यसैले द्विदिशात्मक अनुप्रयोगलाई स्वाभाविक रूपमा TLS को सट्टा VPN चाहिँदैन। उल्टो पनि सत्य हो: त्यही उपकरणमा अन्य प्रोटोकलका लागि तैनाथीलाई अझै VPN चाहिन सक्छ।
उपकरणले के प्रमाणित गर्नुपर्छ निर्णय गर्नुहोस्
सर्भर पहिचानको प्रमाणीकरण र इच्छित विश्वास-मूल कन्फिगर गर्नुहोस्। यदि प्रत्येक उपकरणले आफ्नै पहिचान प्रमाणित गर्नुपर्छ भने समर्थित क्लाइन्ट-प्रमाणीकरण मोडेल छान्नुहोस् र प्रत्येक उपकरणका लागि छुट्टै प्रमाणपत्र दर्ता गर्नुहोस्। साझा प्रमाणहरूले एउटा चोरिएको उपकरणलाई सम्पूर्ण बेडाको समस्या बनाउँछन्।
पठाउनु अघि कुञ्जी सुरक्षा, नवीकरण, रद्दीकरण र पुनःप्राप्तिको योजना बनाउनुहोस्। असफल नवीकरणपछि पुनः दर्ता गर्न नसकिने फिल्डको उपकरण स्थल भ्रमणमा परिणत हुन्छ, र त्यो लागतले ह्यान्डशेकभन्दा बढी डिजाइनलाई आकार दिन्छ।
समर्थित पुस्तकालय र वर्तमान मार्गदर्शन प्रयोग गर्नुहोस्। आधुनिक TLS तैनाथी मार्गदर्शन TLS 1.0 र 1.1 मा वार्ता निषेध गर्छन्, र पुरानो डिजाइन टिप्पणीमा TLSv1 उल्लेख आवश्यकता होइन।
ह्यान्डशेक असफल हुँदा बन्द रहनुहोस्
असफल ह्यान्डशेक वा असफल पहिचान जाँच चुपचाप मूल स्पष्ट-पाठ प्रोटोकलमा फर्कनु हुँदैन। त्यही फर्काइ त्यो दुर्बलता हो जुन TLS कामले बन्द गर्नुपर्ने थियो। असफलतालाई उपकरण सञ्चालक र सेवाका लागि देखिने बनाउनुहोस्, र संवेदनशील कार्यका लागि सुरक्षित च्यानल अनिवार्य गर्नुहोस्। त्यसपछि प्रमाणित उपकरणले के गर्न सक्छ भन्ने अनुप्रयोग अधिकारले निर्णय गरोस्।
जडानको आयु, फ्रेमिङ, समयसीमा र पुनःप्रयास व्यवहारलाई सम्झौताको भागका रूपमा परिभाषित गर्नुहोस्। इन्क्रिप्शनले दोहोरिने आदेशलाई सुरक्षित बनाउँदैन, र अनिश्चित अघिल्लो कार्यपछिको पुनःप्रयासलाई अनुप्रयोग स्तरको उत्तर चाहिन्छ।
फर्काइको नियम लेख्नुहोस्। “ह्यान्डशेक असफल भएमा यो TLS बिना फेरि जोडिन्छ” एउटा डिजाइन निर्णय हो, र त्यो स्पष्ट हुनुपर्छ।
VPN लाई गर्न सक्ने काम मात्र दिनुहोस्
VPN ले पहुँच सीमित गर्न सक्छ र आफ्नै सहकर्मीसम्म प्याकेट सुरक्षित गर्न सक्छ। TLS ले छानिएको अन्त्य बिन्दुसँग अनुप्रयोगको सम्बन्ध सुरक्षित गर्छ। तिनीहरूका अन्त्य बिन्दु फरक हुन सक्छन्, र कुनैले पनि अन्त्य बिन्दुको भण्डारित डेटा वा प्रशासनिक पहुँच सुरक्षित गर्दैन।
एउटा संयन्त्र छिटो छ भनी मान्नुको सट्टा वास्तविक उपकरणमा ह्यान्डशेकको लागत, स्थिर सन्देश आदानप्रदान र पुनःजडान मापन गर्नुहोस्। त्यसपछि महत्त्वपूर्ण चार अवस्था परीक्षण गर्नुहोस्: इच्छित आदानप्रदान, गलत सर्भर पहिचान, अनधिकृत उपकरण, र अनिश्चित कार्यपछिको पुनःजडान। प्रत्येक अवस्थाको नतिजा, उपकरणले देखाउने त्रुटि सहित, अभिलेख गर्नुहोस्।