छोटे दफ़्तर का VPN: इसे डोमेन कंट्रोलर से दूर रखें

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

डोमेन की हर मशीन डोमेन कंट्रोलर पर भरोसा करती है; VPN गेटवे तक इंटरनेट पर कोई भी पहुँच सकता है। यही असमानता पूरा तर्क है।

दो अलग-अलग जोखिम प्रोफ़ाइल वाले दो काम

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

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

निर्देशिका भूमिका के बिना प्रमाणीकरण

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

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

एक होस्ट अभी भी एक विफलता डोमेन है

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

इसलिए एक स्वतंत्र प्रबंधन पथ की योजना बनाएँ जो सुरंग पर निर्भर न हो, और लिखें कि रखरखाव के दौरान क्या उपलब्ध रहता है। गेटवे अपडेट और निर्देशिका रखरखाव को अलग-अलग निर्धारित करें, यह नोट करते हुए कि प्रत्येक रुकावट किन उपयोगकर्ताओं या अनुप्रयोगों को छूती है।

जिस रखरखाव विंडो में VPN ठीक करने के लिए VPN चालू होना आवश्यक है, वह रखरखाव विंडो नहीं है।

बाहर ताला लगाए बिना इसे स्थानांतरित करें

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

लक्ष्य सुंदर आरेख नहीं है। पूरे दफ़्तर के लिए निर्देशिका भरोसे को स्थिर करने वाले बक्से को छुए बिना VPN को ठीक या पुनर्निर्मित करने की क्षमता है। ये अलग उद्देश्य हैं, और इनमें से केवल एक को दूसरा सर्वर चाहिए।

निर्णय किसी भी तरह दर्ज करें, उन शर्तों सहित जो उसे फिर से खोल सकती हैं। छोटा दफ़्तर बढ़ता है, और एक सर्वर पर फिट बैठा उत्तर अगले पर न बैठे।