RDP तक कौन पहुँच सकता है इसे प्रतिबंधित करें, जहाँ समर्थित हो वहाँ Network Level Authentication सक्षम रखें, व्यक्तिगत मजबूत क्रेडेंशियल उपयोग करें और प्रशासनिक विशेषाधिकार कम करें। वर्तमान कनेक्शन बंद करने से पहले दूसरे सत्र और रिकवरी पहुँच का परीक्षण करें।
डेस्कटॉप को प्रशासन सीमा मानें
एक RDP सत्र दूरस्थ सिस्टम तक इंटरैक्टिव पहुँच प्रदान करता है, इसलिए इसके लिए उपयोग किया गया खाता मूल्यवान लक्ष्य बन सकता है। यह तय करके शुरू करें कि किसे पहुँच चाहिए और उन्हें कौन-सा कार्य करना है। साझा प्रशासक लॉगिन तब तक सुविधाजनक है जब तक आपको किसी एक व्यक्ति की पहुँच हटानी न हो या कॉन्फ़िगरेशन परिवर्तन समझना न हो। व्यक्तिगत खाते उन परिचालन कार्यों को स्पष्ट बनाते हैं।
जहाँ सॉफ़्टवेयर अनुमति देता है वहाँ नियमित गतिविधि को विशेषाधिकार प्राप्त परिवर्तनों से अलग करें। जिस उपयोगकर्ता को व्यावसायिक एप्लिकेशन चाहिए उसे अनिवार्य रूप से अप्रतिबंधित सिस्टम प्रशासन की आवश्यकता नहीं होती। प्रशासक के एंडपॉइंट को भी बनाए रखें: दूरस्थ मशीन को सुरक्षित करना संक्रमित या साझा स्थानीय डिवाइस से दर्ज क्रेडेंशियल की रक्षा नहीं करता। पहुँच डिज़ाइन में सत्र के दोनों सिरों पर विचार करें।
लॉगिन सुरक्षा पर निर्भर होने से पहले पहुँच-योग्यता सीमित करें
तय करें कि कौन-से नेटवर्क या अधिकृत डिवाइस सत्र होस्ट तक पहुँच सकते हैं। जहाँ आपकी आर्किटेक्चर समर्थन करती है, प्रशासन को व्यापक रूप से उजागर करने के बजाय नियंत्रित VPN या Remote Desktop Gateway का उपयोग करें। Microsoft RD Gateway को कनेक्शन और संसाधन प्राधिकरण नीतियों के साथ आंतरिक संसाधनों तक मार्ग के रूप में दस्तावेज़ करता है। इसकी उपयुक्तता वातावरण पर निर्भर करती है; केवल इसलिए शामिल सुविधा नहीं है कि कोई प्लान RDP का समर्थन करता है।
फ़ायरवॉल नियमों को इच्छित पथ तक सीमित करें, और पुष्टि करें कि गतिशील क्लाइंट पते कैसे संभाले जाएंगे। ऐसा प्रतिबंधात्मक नियम न बनाएं जो रिकवरी विकल्प के बिना एकमात्र प्रशासक को तुरंत डिस्कनेक्ट कर दे। मौजूदा सत्र खुला रखें, दूसरे सत्र से नए पथ का परीक्षण करें और पुराना पहुँच मार्ग हटाने से पहले अधिकृत रिकवरी तंत्र का दस्तावेज़ीकरण करें।
प्रमाणीकरण और विश्वास स्पष्ट रखें
Microsoft अधिकांश समर्थित वातावरणों के लिए Network Level Authentication की सिफारिश करता है। NLA पूर्ण दूरस्थ सत्र स्थापित करने से पहले प्रमाणीकरण की आवश्यकता रखता है, जिससे उस चरण में सुरक्षा जुड़ती है। यह फ़ायरवॉल, खाता नीति या सिस्टम अपडेट को प्रतिस्थापित नहीं करता। क्लाइंट संगतता जाँचें और पहली प्रतिक्रिया के रूप में कॉन्फ़िगरेशन को स्थायी रूप से कमजोर करने के बजाय प्रमाणीकरण समस्याओं का निवारण करें।
जहाँ संभव हो समर्थित पहुँच आर्किटेक्चर के माध्यम से अद्वितीय क्रेडेंशियल और दूसरा कारक उपयोग करें। अपेक्षित दूरस्थ पहचान और प्रमाणपत्र व्यवहार सत्यापित करें, विशेष रूप से पुनर्निर्माण या होस्टनाम परिवर्तन के बाद। प्रमाणपत्र चेतावनी जाँच के योग्य है; अनपेक्षित पहचानों को बार-बार स्वीकार करना उपयोगी विश्वास जाँच को अनदेखा किए गए संवाद में बदल देता है। रिकवरी क्रेडेंशियल को अनुमोदित निजी भंडार में रखें।
| परत | निर्णय | सत्यापन |
|---|---|---|
| नेटवर्क | कौन-से क्लाइंट होस्ट तक पहुँच सकते हैं? | अनपेक्षित स्रोत कनेक्ट नहीं कर सकते |
| प्रमाणीकरण | कौन-सा खाता और कारक आवश्यक हैं? | एक अनुमत दूसरा सत्र सफल होता है |
| विशेषाधिकार | किन कार्यों के लिए प्रशासन आवश्यक है? | नियमित उपयोगकर्ता सिस्टम सेटिंग्स नहीं बदल सकते |
| पुनर्प्राप्ति | गलती के बाद पहुँच कैसे बहाल होती है? | दस्तावेज़ीकृत रिकवरी पथ उपलब्ध है |
सत्र जो ले जा सकता है उसे कम करें
क्लिपबोर्ड, ड्राइव, प्रिंटर और अन्य रीडायरेक्शन सुविधाओं की वास्तविक वर्कफ़्लो के विरुद्ध समीक्षा करें। प्रशासक को दूरस्थ होस्ट पर हर स्थानीय संसाधन उजागर करने की आवश्यकता नहीं हो सकती। इसके विपरीत, विकल्प के बिना आवश्यक स्थानांतरण पथ अक्षम करना असुरक्षित वर्कअराउंड को प्रोत्साहित कर सकता है। फ़ाइलें स्थानांतरित करने की अनुमत विधि का दस्तावेज़ीकरण करें, और रहस्यों को सामान्य डेस्कटॉप नोट्स या साझा डाउनलोड निर्देशिकाओं से बाहर रखें।
उपयुक्त डोमेन-आधारित वातावरणों के लिए, Microsoft RDP कनेक्शन के दौरान क्रेडेंशियल एक्सपोज़र कम करने के लिए Remote Credential Guard प्रदान करता है। इसके लिए संगत क्लाइंट और Kerberos प्रमाणीकरण आवश्यक है और यह लक्ष्य मशीन से सीधे कनेक्शन का समर्थन करता है; Remote Desktop Gateway या Connection Broker के माध्यम से कनेक्शन समर्थित नहीं हैं। इसे स्टैंडअलोन होस्टेड Windows मशीनों के लिए सार्वभौमिक सुरक्षा मानने के बजाय अपने वास्तविक पहुँच पथ की आवश्यकताएँ जाँचें।
मशीन और आवश्यक साक्ष्य बनाए रखें
ऑपरेटिंग सिस्टम और एप्लिकेशन अपडेट शेड्यूल करें, जिसमें जानबूझकर पुनः आरंभ प्रक्रिया शामिल हो। जाँचें कि क्या किसी अपडेट के लिए रीबूट आवश्यक है और बाद में सेवा सत्यापित करें। अनुपस्थित या डिस्कनेक्टेड कार्य के लिए उचित सत्र नीतियाँ निर्धारित करें, लेकिन उन एप्लिकेशनों पर विचार करें जिन्हें चलते रहना चाहिए। टाइमआउट नीति को किसी अन्य वातावरण से मनमाना नंबर कॉपी करने के बजाय सुरक्षा या परिचालन आवश्यकता का उत्तर देना चाहिए।
दस्तावेज़ीकृत नीति के अंतर्गत उपयोगी पहुँच और घटना जानकारी रखें। अनावश्यक सामग्री एकत्र किए बिना बार-बार प्रमाणीकरण विफलताओं और अनपेक्षित प्रशासन गतिविधि की निगरानी करें। प्रतिबंधित करें कि कौन नैदानिक रिकॉर्ड पढ़ सकता है और तय करें कि उनकी कितने समय तक आवश्यकता है। सटीक लॉगिंग नीति अनिश्चितकाल तक सब कुछ रखने या यह वादा करने से अधिक अर्थपूर्ण है कि कोई परिचालन रिकॉर्ड कभी मौजूद नहीं हो सकता।
एक सुरक्षित प्रथम-सत्र अनुक्रम
डिलीवरी पर, अपेक्षित सिस्टम सत्यापित करें, अनुमोदित प्रक्रिया के माध्यम से अस्थायी क्रेडेंशियल बदलें और व्यक्तिगत पहुँच स्थापित करें। फ़ायरवॉल और रिकवरी मार्ग की पुष्टि करें, फिर दूसरा कनेक्शन परीक्षण करें। अपडेट लागू करें, रीडायरेक्शन की समीक्षा करें और आवश्यक एप्लिकेशन इंस्टॉल करें। दैनिक कार्य के लिए डेस्कटॉप पर निर्भर होने से पहले बैकअप बनाएं और महत्वपूर्ण सेटिंग्स को पुनर्प्राप्त करने का अभ्यास करें।
DeskLink RDP और चयनित समर्पित कॉन्फ़िगरेशन SwissOctet कैटलॉग में Windows-संबंधित विकल्प प्रदान करते हैं। अपने ऑर्डर के लिए ऑपरेटिंग सिस्टम, लाइसेंसिंग, खाता विशेषाधिकार और प्रबंधन जिम्मेदारियों की पुष्टि करें। समर्थित डेस्कटॉप कनेक्शन प्रशासन योजना की शुरुआत है; आपके द्वारा कॉन्फ़िगर और सत्यापित किए गए नियंत्रण तय करते हैं कि उस पहुँच का उपयोग कैसे किया जाता है।
आपकी व्यावहारिक चेकलिस्ट।
- व्यक्तिगत खाते और उचित विशेषाधिकार उपयोग करें।
- इच्छित RDP पहुँच पथ को प्रतिबंधित करें।
- संगत सिस्टम पर NLA सक्षम रखें।
- वर्तमान पहुँच बंद करने से पहले दूसरे सत्र का परीक्षण करें।
- रीडायरेक्शन, अपडेट और सत्र नीति की समीक्षा करें।
- लाइसेंसिंग और रिकवरी प्रक्रिया की पुष्टि करें।
महत्वपूर्ण विवरण।
क्या NLA उजागर RDP होस्ट को पूरी तरह सुरक्षित बनाता है?+
नहीं। NLA एक प्रमाणीकरण नियंत्रण है। पहुँच-योग्यता, क्रेडेंशियल, अपडेट और विशेषाधिकार पर अभी भी ध्यान देने की आवश्यकता है।
क्या मैं हर Windows सर्वर पर Remote Credential Guard का उपयोग कर सकता हूँ?+
नहीं। क्लाइंट, होस्ट और प्रमाणीकरण वातावरण को Microsoft की आवश्यकताओं को पूरा करना होगा, जिसमें लागू Kerberos व्यवस्था भी शामिल है।
फ़ायरवॉल को कड़ा करने से पहले मुझे क्या करना चाहिए?+
एक रिकवरी मार्ग सत्यापित करें, कार्यशील सत्र को सुरक्षित रखें और दूसरे कनेक्शन के माध्यम से नए अनुमत पथ का परीक्षण करें।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- Microsoft: Remote Desktop और Network Level Authentication सक्षम करें learn.microsoft.com
- Microsoft: Remote Desktop Gateway पहुँच learn.microsoft.com
- Microsoft: Remote Credential Guard learn.microsoft.com
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।