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