असे रिमोट-अ‍ॅक्सेस उपकरण सुचवा जे नेटवर्कचा मालक मंजूर करू शकेल
क्लायंटच्या नेटवर्कला स्पर्श करण्यापूर्वी संसाधन, ओळख, विश्वासाची सीमा आणि काढण्याचा मार्ग निश्चित करा। मंजुरी हाच निकाल आहे।
रिमोट-अ‍ॅक्सेस उपकरण क्लायंटच्या नेटवर्कची सीमा बदलते, तेव्हाही जेव्हा ते बाहेरच्या दिशेने जोडले जाते आणि त्याला आत येणारे कोणतेही पोर्ट फॉरवर्डिंग लागत नाही। बाहेरची दिशाच त्याला स्थापित करणे सोपे आणि दुर्लक्ष करणे सोपे बनवते। नेटवर्कवर जाण्यापूर्वी ते अ‍ॅक्सेस-डिझाइन विनंती म्हणून सादर करा। ज्याचा उल्लेख करण्याची गरज नव्हती अशी गोष्ट म्हणून सादर करणे हाच असा मार्ग आहे की ज्यातून तांत्रिक यश कराराची समस्या बनते।
असे गृहीत धरा की नेटवर्कचा मालक चार प्रश्न विचारेल: काय, कोण, किती दूर, आणि आपण ते कसे मागे घेऊ?
संसाधन मागा, सबनेट नाही
काम मालक वापरतो त्या शब्दांत वर्णन करा: कोणत्या व्यक्तीला कोणती सेवा, कोणत्या उपकरणावर आणि किती काळासाठी हवी आहे। एका होस्टवरील एका अ‍ॅप्लिकेशनपुरती मर्यादित विनंती मंजूर करणे सोपे आहे। सबनेटची विनंती म्हणजे दुसऱ्या कोणाचे विभाजन पुन्हा रचण्याची विनंती।
कदाचित क्लायंट आधीच मंजूर VPN, रिमोट डेस्कटॉप गेटवे किंवा व्यवस्थापित सपोर्ट चॅनेल चालवत असेल जे गरज पूर्ण करते। ते आधी तपासा, कारण विद्यमान मार्गाचा पुनर्वापर सामान्यतः दोन्ही बाजूंसाठी सर्वात स्वस्त उत्तर असतो। जर ते जुळत नसेल, तर नक्की का ते सांगा। तीच तुलना प्रस्तावाचा सर्वात मजबूत भाग आहे।
जर उपकरण खरोखर आवश्यक असेल, तर त्याचा मालक, सॉफ्टवेअरचा स्रोत, अपडेट प्रक्रिया आणि इच्छित इंस्टॉलेशन जागा सोबत आणा।
कनेक्शन आणि विश्वास कुठे संपतो ते दाखवा
उपकरण, दूरस्थ वापरकर्ता, कोणताही ब्रोकर किंवा रिले आणि संरक्षित संसाधन रेखाटा। एन्क्रिप्शन कुठे संपते आणि प्रत्येक टोकाचे व्यवस्थापन कोण करते ते चिन्हांकित करा। बाहेर जाणारे सत्र तरीही नवीन नियंत्रण मार्ग आणते, आणि आकृतीतच ते दिसते। रहदारी एन्क्रिप्टेड आहे असे म्हणणे गोपनीयतेच्या प्रश्नाचे उत्तर देते आणि परवानगीच्या कोणत्याही प्रश्नाचे नाही।
मोड स्पष्ट सांगा: पॅकेट फॉरवर्डिंग, अ‍ॅप्लिकेशन प्रॉक्सी किंवा उघडे डेस्कटॉप। प्रत्येकाचे राउटिंग आणि होस्ट सुरक्षेवर वेगळे परिणाम असतात, आणि उपकरणाशी छेडछाड झाल्यास प्रत्येक वेगळ्या प्रकारे अपयशी ठरते।
असंबंधित क्लायंट नेटवर्क आणि उपकरणाचे स्वतःचे प्रशासन इंटरफेस मंजूर कक्षेबाहेर ठेवा।
वापरकर्त्याची ओळख उपकरणाच्या ओळखीपासून वेगळी करा
वापरकर्ता नोंदणी, उपकरणाची ओळख, बहु-घटक प्रमाणीकरण आणि अ‍ॅप्लिकेशन लॉगिन हे चार वेगळे नियंत्रण आहेत, आणि प्रस्तावाने प्रत्येकाचे नाव घ्यायला हवे। सामायिक क्रेडेन्शियल्स हा नेहमीचा शॉर्टकट आहे, आणि ते मालकाला सर्वांना अडवून न एक व्यक्ती रद्द करण्यास असमर्थ ठेवतात। लॉगिन अ‍ॅप्लिकेशनकडेच राहिले पाहिजे। उपकरण कनेक्शनची प्रमाणितता करते; सेवा ठरवते की ते कनेक्शन काय करू शकते।
NISTची शून्य-विश्वास स्थापत्यरचना इथे उपयुक्त आहे कारण ती संसाधन प्रवेशाला स्पष्ट निर्णय मानते, नेटवर्क स्थानाचा परिणाम नाही।
इंस्टॉलेशनपूर्वी पुनर्प्राप्ती आणि काढण्यावर सहमती द्या
मालकाने स्वतः चालवतो त्या नियंत्रणाद्वारे प्रवेश त्वरित बंद करता आला पाहिजे, तुम्हाला फोन करून नाही। क्रेडेन्शियल्स रद्द करणे, उपकरण काढणे, अपडेटची जबाबदारी आणि मुदत संपण्याची किंवा पुनरावलोकनाची तारीख लिहा। स्थानिक पुनर्प्राप्ती मार्ग ठेवा जो नव्या दूरस्थ चॅनेलवर अवलंबून नाही। जे उपकरण वेंडरशिवाय कोणीही काढू शकत नाही ते सोयीच्या वेशातील कायमचे अवलंबन आहे।
नोंदी प्रमाणात ठेवा: मंजूर ओळख, प्रवेश कक्षा, महत्त्वाचे बदल आणि संबंधित अपयश।
असंबंधित ब्राउझिंग इतिहास गोळा करणे हे उपकरण अस्तित्वात आहे हे सिद्ध करण्यासाठी चांगल्या कारभाराचा पुरावा नाही, आणि ते असे बंधन निर्माण करते जे मालकाने कधीही मागितले नाही।
यशस्वी मंजुरी कशी दिसते
रचना मालकासोबत एका मंजूर सेवेसह आणि नाकारलेलेच राहिले पाहिजे अशा एका संसाधनासह स्वीकारा। तोच दुसरा अर्धा भाग लोक वगळतात, आणि सीमा आकृती सांगते तिथेच आहे हे सिद्ध करणारा तोच एकमेव भाग आहे। रद्द करण्याचीही तशीच चाचणी करा, उपकरण खरे काम घेण्यापूर्वी। मंजुरी न मिळाल्यास क्लायंटचा मंजूर पर्याय वापरा किंवा काम स्थानिक पातळीवर करा।
चालू कनेक्शन ही प्रवेश मार्ग तयार करण्याची परवानगी नाही।
मंजुरी तिच्या कक्षेसह आणि मुदतीसह लिहा, आणि मालकाला एक प्रत द्या। त्या नेटवर्कला स्पर्श करणारी पुढील व्यक्ती नोंद वाचेल, संभाषणाची तुमची आठवण नाही।