ऐसा रिमोट-एक्सेस उपकरण प्रस्तावित करें जिसे नेटवर्क मालिक स्वीकृत कर सके

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

मान लें कि नेटवर्क मालिक चार सवाल पूछेगा: क्या, कौन, कितनी दूर, और हम इसे कैसे वापस लेंगे?

संसाधन मांगें, सबनेट नहीं

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

हो सकता है क्लाइंट पहले से कोई स्वीकृत VPN, रिमोट डेस्कटॉप गेटवे या प्रबंधित सपोर्ट चैनल चला रहा हो जो ज़रूरत पूरी करता है। पहले वही जाँचें, क्योंकि मौजूदा रास्ते का दोबारा उपयोग आम तौर पर दोनों पक्षों के लिए सबसे सस्ता जवाब होता है। अगर वह फ़िट नहीं बैठता, तो ठीक-ठीक बताएं क्यों। वही तुलना प्रस्ताव का सबसे मज़बूत हिस्सा है।

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

कनेक्शन और वह जगह दिखाएं जहाँ भरोसा खत्म होता है

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

मोड स्पष्ट बताएं: पैकेट फ़ॉरवर्डिंग, एप्लिकेशन प्रॉक्सी या खुला डेस्कटॉप। हर एक के रूटिंग और होस्ट सुरक्षा पर अलग परिणाम होते हैं, और उपकरण के समझौता होने पर हर एक अलग तरह से विफल होता है।

असंबंधित क्लाइंट नेटवर्क और उपकरण का अपना प्रशासन इंटरफ़ेस स्वीकृत दायरे से बाहर रखें।

उपयोगकर्ता पहचान को उपकरण पहचान से अलग करें

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

NIST की ज़ीरो-ट्रस्ट आर्किटेक्चर यहाँ उपयोगी है क्योंकि वह संसाधन पहुँच को एक स्पष्ट निर्णय मानती है, नेटवर्क स्थान का परिणाम नहीं।

इंस्टॉलेशन से पहले रिकवरी और हटाने पर सहमत हों

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

रिकॉर्ड अनुपात में रखें: स्वीकृत पहचान, पहुँच का दायरा, महत्वपूर्ण बदलाव और प्रासंगिक विफलताएँ।

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

सफल स्वीकृति कैसी दिखती है

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

चालू कनेक्शन एक्सेस मार्ग बनाने की अनुमति नहीं है।

स्वीकृति को उसके दायरे और उसकी समाप्ति के साथ लिखें, और मालिक को एक प्रति दें। उस नेटवर्क को छूने वाला अगला व्यक्ति रिकॉर्ड पढ़ेगा, बातचीत की आपकी याद नहीं।