Protective DNS की व्याख्या: यह कैसे काम करता है और क्यों महत्वपूर्ण है
Published
होटल लॉबी में एक अतिथि एक लिंक पर टैप करता है, और पेज लोड होना शुरू हो जाता है। इससे पहले कि ब्राउज़र वेबसाइट से कनेक्ट हो सके, अतिथि के डिवाइस को यह पता लगाना होगा कि वह साइट इंटरनेट पर कहां स्थित है। वह शांत लुकअप यह जांचने का एक अवसर है कि क्या गंतव्य की अनुमति दी जानी चाहिए।
सुरक्षात्मक DNS इस नियमित चरण में एक सुरक्षा निर्णय जोड़ता है। यह संगठनों को साझा नेटवर्क पर लोगों और उपकरणों की सुरक्षा करने में मदद कर सकता है, लेकिन यह तभी काम करता है जब उनका ट्रैफ़िक प्रबंधित हलकर्ता (resolver) का उपयोग करता है। उस अंतर को समझने से प्रदर्शन, अपवादों, बायपास मार्गों और गोपनीयता के लिए योजना बनाना आसान हो जाता है।
विषय-सूची
- हर वेबसाइट विज़िट DNS लुकअप से क्यों शुरू होती है
- नाम-रिजोल्यूशन चरण में Protective DNS क्या काम करता है
- पूरे नेटवर्क में नीति प्रवर्तन कैसे काम करता है
- प्रदर्शन प्रभाव और मापने योग्य पेज-लोड लाभ
- स्थानों और उद्यमों में वास्तविक दुनिया के उपयोग के मामले
- अपने नेटवर्क के लिए सही दृष्टिकोण चुनना
- ब्लॉक की गई संख्याओं से परे Protective DNS मूल्य को मापना
- अपने Protective DNS रोलआउट की योजना बनाने के लिए अगले कदम
हर वेबसाइट विज़िट DNS लुकअप से क्यों शुरू होती है
वेबसाइट का नाम याद रखना लोगों के लिए आसान होता है। कंप्यूटरों को कनेक्ट करने के लिए एक नेटवर्क पते की आवश्यकता होती है। Domain Name System (DNS) यह अनुवाद प्रदान करता है, बिल्कुल एक फोन बुक की तरह जो किसी व्यक्ति के नाम को एक नंबर में बदल देती है जिसे आप डायल कर सकते हैं।
जब अतिथि लिंक पर टैप करता है, तो ब्राउज़र DNS रिसॉल्वर से वेबसाइट के नाम से जुड़े पते के बारे में पूछता है। रिसॉल्वर उत्तर खोजता है और इसे वापस भेजता है। इसके बाद ब्राउज़र गंतव्य से जुड़ने का प्रयास कर सकता है। DNS पेज को स्वयं नहीं ले जाता है, लेकिन यह डिवाइस को यह खोजने में मदद करता है कि अनुरोध कहां करना है।
वह क्रम एक उपयोगी सुरक्षा जांच बिंदु बनाता है। यदि हलकर्ता (resolver) किसी अनुरोधित डोमेन को ज्ञात खतरे के रूप में पहचानता है, तो ब्राउज़र के कनेक्ट होने से पहले वह एक उपयोगी उत्तर देने से इंकार कर सकता है। एक सुरक्षात्मक DNS सेवा डाउनलोड की गई फ़ाइल या एंडपॉइंट पर किसी संदिग्ध कार्रवाई की प्रतीक्षा करने के बजाय, इसी लुकअप चरण में सुरक्षा नीतियों को लागू करती है।
व्यावहारिक अंतर: DNS एक डिवाइस को गंतव्य ढूंढने में मदद करता है। Protective DNS यह निर्णय जोड़ता है कि क्या लुकअप सफल होना चाहिए या नहीं।
यह विशेष रूप से उन स्थानों पर मायने रखता है जहां कई लोग और डिवाइस नेटवर्क इंफ्रास्ट्रक्चर साझा करते हैं। एक होटल में मेहमानों के फोन, कर्मचारियों के लैपटॉप, पेमेंट टर्मिनल और कनेक्टेड बिल्डिंग उपकरण एक ही समग्र नेटवर्क के विभिन्न हिस्सों का उपयोग कर सकते हैं। एक कार्यालय, आवासीय संपत्ति, या सार्वजनिक स्थल को भी इसी तरह की चुनौती का सामना करना पड़ता है, भले ही उपयोगकर्ता और डिवाइस अलग-अलग हों।
सुरक्षात्मक DNS उन लुकअप के लिए एक सामान्य चेकपॉइंट प्रदान कर सकता है, लेकिन यह एक संपूर्ण सुरक्षा कार्यक्रम नहीं है। यह उस उपकरण की रक्षा नहीं करेगा जो प्रबंधित रिसॉल्वर से बचता है, और यह एंडपॉइंट सुरक्षा, पहुंच नियंत्रण, या सावधानीपूर्वक नेटवर्क डिज़ाइन को प्रतिस्थापित नहीं करता है। उपयोगी प्रश्न यह हैं कि रिसॉल्वर अपना निर्णय कैसे लेता है, एक संगठन उपकरणों को लक्षित पथ पर कैसे रखता है, और कौन से साक्ष्य दिखाते हैं कि सेवा बिना किसी व्यवधान के मदद कर रही है।
नाम - रेजोल्यूशन चरण में प्रोटेक्टिव DNS क्या करता है
सुरक्षात्मक DNS एक नीति-लागू करने वाला पुनरावर्ती (recursive) रिसॉल्वर है। एक पुनरावर्ती रिसॉल्वर किसी डिवाइस की ओर से अनुरोधों को संभालता है, जबकि सुरक्षात्मक DNS यह तय करने के लिए नियम लागू करता है कि अनुरोधित गंतव्य को सामान्य DNS उत्तर मिलना चाहिए या नहीं। यह केवल तेज़ या एन्क्रिप्टेड बनाया गया DNS नहीं है।
शुरू से अंत तक एक लुकअप का पालन करें:
- डिवाइस डोमेन नाम मांगता है। एक ब्राउज़र, ऐप, या अन्य प्रक्रिया को किसी नाम वाले गंतव्य से जुड़ने का प्रयास करने से पहले एक पते की आवश्यकता होती है।
- हलकर्ता (resolver) अनुरोध की जाँच करता है। यह कॉन्फ़िगर की गई नीतियों और खतरे की जानकारी के खिलाफ डोमेन की तुलना करता है। मजबूत कार्यान्वयन एक हल किए गए IP पते की भी जाँच कर सकते हैं, जो किसी नाम के पीछे इंफ्रास्ट्रक्चर का मूल्यांकन करने में मदद करता है।
- हलकर्ता परिणाम देता है। यदि नीति अनुरोध की अनुमति देती है, तो हलकर्ता एक उत्तर प्रदान करता है। यदि यह अनुमति नहीं देता है, तो सेवा रिज़ॉल्यूशन को अवरुद्ध कर सकती है, एक खाली प्रतिक्रिया दे सकती है, या क्लाइंट को एक चेतावनी पृष्ठ पर रीडायरेक्ट कर सकती है। सटीक व्यवहार उत्पाद और नीति पर निर्भर करता है।
कुछ कार्यान्वयन एल्गोरिथम रूप से उत्पन्न डोमेन या DGA की तलाश करते हैं, जिनका उपयोग मैलवेयर कमांड-एंड-कंट्रोल इंफ्रास्ट्रक्चर खोजने के लिए कर सकता है। डोमेन के वर्णों में असामान्य पैटर्न, उच्च एन्ट्रापी सहित, आगे की नीति मूल्यांकन के लिए एक संकेत के रूप में कार्य कर सकते हैं। उस तरह का विश्लेषण खतरे-खुफिया फीड का पूरक हो सकता है, लेकिन संगठनों को अभी भी यह सत्यापित करने की आवश्यकता है कि उनकी चुनी हुई सेवा पहचान और अपवादों को कैसे संभालती है।
एन्क्रिप्शन और प्रामाणिकता सुरक्षा के निर्णय के समान नहीं हैं
DNSSEC हस्ताक्षर किए गए DNS डेटा की अखंडता और प्रामाणिकता को सत्यापित करने में मदद करता है। DNS over HTTPS (DoH) और DNS over TLS (DoT) पारगमन में DNS प्रश्नों की सुरक्षा करते हैं। वे गुण मायने रखते हैं, लेकिन वे अपने आप में यह निर्धारित नहीं करते हैं कि कोई मौजूदा डोमेन दुर्भावनापूर्ण है या नहीं। सुरक्षात्मक DNS वह नीति निर्णय हलकर्ता (resolver) पर लेता है।
वेब एक्सेस और क्लाउड सेवाओं के आसपास नियंत्रणों की समीक्षा करने वाली टीमों के लिए, यह अंतर Microsoft 365 बिज़नेस एनवायरनमेंट को सुरक्षित करने पर व्यापक मार्गदर्शन के साथ रह सकता है। मुख्य बात यह है कि एन्क्रिप्टेड ट्रांसपोर्ट या प्रमाणित डेटा को गंतव्य जोखिम के बारे में किसी निर्णय के विकल्प के रूप में मानने से बचा जाए।
पूरे नेटवर्क में नीति प्रवर्तन कैसे काम करता है
एक रिसॉल्वर किसी एक अनुरोध के लिए सही निर्णय ले सकता है और फिर भी नेटवर्क की सुरक्षा करने में विफल हो सकता है यदि डिवाइस इसके आसपास DNS को रूट कर सकते हैं। इसलिए पूरे एस्टेट में तैनाती दो जुड़ी हुई बातों के बारे में है: संगत नीति और रिसॉल्वर के लिए एक भरोसेमंद मार्ग।
एक केंद्रीकृत डिज़ाइन कई साइटों से एक प्रबंधित सेवा में DNS अनुरोध भेजता है। यह साझा नियमों को लागू करना और विभिन्न स्थानों पर गतिविधियों की समीक्षा करना आसान बनाता है। यह उपलब्धता को एक सुरक्षा आवश्यकता भी बनाता है। यदि हलकर्ता (resolver) तक पहुँचा नहीं जा सकता है, तो सामान्य वेब पहुँच और DNS पर निर्भर सेवाएँ नेटवर्क के बाकी हिस्सों के चालू रहने पर भी विफल हो सकती हैं।
अमेरिकी सरकार की प्रोटेक्टिव DNS सेवा सितंबर 2022 में फेडरल सिविलियन एग्जीक्यूटिव ब्रांच एजेंसियों के लिए उपलब्ध हुई। अगस्त 2024 तक, 104 से अधिक एजेंसियां शामिल हो चुकी थीं, जो रोजाना औसतन 1.6 बिलियन सुरक्षित DNS प्रश्न उत्पन्न करती थीं; कार्यक्रम ने 99.999% रिज़ॉल्वर अपटाइम की सूचना दी (CISA का प्रोटेक्टिव DNS तथ्य पत्रक)। परिचालन संबंधी सबक यह है कि फ़िल्टरिंग गुणवत्ता और सेवा उपलब्धता का मूल्यांकन एक साथ करने की आवश्यकता है।
नीतियां बढ़ाए बिना पहचान लागू करें
कर्मचारियों, मेहमानों, निवासियों और जुड़े हुए उपकरणों को आवश्यक रूप से एक ही नियम की आवश्यकता नहीं होती है। एक नेटवर्क पहचान या नेटवर्क सेगमेंट के आधार पर अलग-अलग नीतियां निर्दिष्ट कर सकता है, जैसे कि कर्मचारी नेटवर्क, अतिथि WiFi, और बिल्डिंग उपकरणों के लिए एक अलग नेटवर्क। इसका उद्देश्य प्रशासन को प्रबंधनीय रखते हुए नीति को उपयोगकर्ता या उपकरण के अनुकूल बनाना है।
एक्सेस कंट्रोल उस अलगाव को स्थापित करने में मदद करते हैं, जबकि नेटवर्क-ट्रैफ़िक मॉनिटरिंग टीमों को असामान्य नेटवर्क गतिविधि की जांच करने में मदद कर सकती है। नेटवर्क एक्सेस कंट्रोल एक प्रबंधित परिवेश में कैसे फिट बैठता है, इसके संबंधित दृश्य के लिए, इन नेटवर्क एक्सेस कंट्रोल समाधानों को देखें।
बायपास मार्गों को जानबूझकर बंद करें
यदि कोई डिवाइस सीधे किसी बाहरी रिसॉल्वर को सामान्य DNS भेज सकता है, तो सुरक्षात्मक सेवा शायद अनुरोध को कभी न देख पाए। DoH और DoT एक और चुनौती पेश करते हैं: एन्क्रिप्शन ट्रांसिट में प्रश्नों की सुरक्षा कर सकता है, लेकिन एक गैर-प्रबंधित रिसॉल्वर उन्हें संगठनात्मक नीति और दृश्यता से भी हटा सकता है।
जहां प्रवर्तन की आवश्यकता होती है, टीमों को सीधे DNS पथों और अनधिकृत एन्क्रिप्टेड-DNS गंतव्यों की पहचान करनी चाहिए, फिर यह तय करना चाहिए कि नेटवर्क, एंडपॉइंट और ब्राउज़र नियंत्रण उन्हें कैसे संभालेंगे। अपवादों का भी परीक्षण करें। Captive Portal, मोबाइल उपकरण, IPv6, और अपनी स्वयं की रिसॉल्वर सेटिंग्स वाले एप्लिकेशन कॉर्पोरेट नेटवर्क पर प्रबंधित लैपटॉप से भिन्न व्यवहार कर सकते हैं। नीति केवल उन्हीं पथों पर काम करती है जिन्हें संगठन शासित कर सकता है।
प्रदर्शन प्रभाव और मापने योग्य पेज - लोड लाभ
सुरक्षात्मक DNS सेवा को ब्राउज़िंग को विशेष रूप से धीमा करने की आवश्यकता नहीं है। इसका प्रभाव फ़िल्टरिंग की क्रिया पर कम और व्यावहारिक डिज़ाइन विकल्पों पर अधिक निर्भर करता है: रिसॉल्वर कहां स्थित है, यह उत्तरों को कैसे कैश करता है, यह कनेक्शन को कैसे बनाए रखता है, और क्या डिवाइस इसे बायपास करते हैं।
एन्क्रिप्टेड DNS सेटअप समय बढ़ा सकता है जब किसी प्रश्न को भेजने से पहले कनेक्शन को TCP, TLS, या HTTP स्थापित करने की आवश्यकता होती है। एक लगातार बने रहने वाले (पर्सिस्टेंट) सत्र का पुन: उपयोग करने से उस सेटअप को बार-बार करने से बचा जा सकता है। एन्क्रिप्टेड DNS प्रदर्शन के स्वतंत्र मापों के अनुसार, TLS 1.3, 0-RTT, HTTP/2 मल्टीप्लेक्सिंग और QUIC भी कनेक्शन ओवरहेड को कम कर सकते हैं। स्वस्थ नेटवर्क स्थितियों के तहत, रॉ लुकअप लेटेंसी नगण्य हो सकती है, लेकिन हर क्लाइंट या नेटवर्क पाथ के लिए इसकी गारंटी नहीं है।
केवल इम्प्रेशन ही नहीं, बल्कि लुकअप का भी परीक्षण करें
एक नजदीकी, अत्यधिक उपलब्ध रिज़ॉल्वर और मानकों के अनुकूल कैशिंग सामान्य लुकअप को त्वरित रखने में मदद करते हैं। लेकिन एक औसत लेटेंसी आंकड़ा उपयोगकर्ताओं के एक वर्ग के लिए या जब रिज़ॉल्वर को ऐसा उत्तर प्राप्त करना होता है जो पहले से कैश में नहीं है, तो धीमी प्रतिक्रिया की समस्या को छिपा सकता है।
कोल और वार्म कैश के लिए अलग-अलग p50, p90, और p99 लुकअप लेटेंसी मापें। मध्यिका (median) एक सामान्य लुकअप दर्शाती है; उच्च प्रतिशतक उन धीमे मामलों को उजागर करते हैं जो उपयोगकर्ताओं को अधिक प्रभावित कर सकते हैं। लुकअप की गति को पूर्ण पेज-लोड समय से अलग रखें, क्योंकि DNS ब्राउज़र की यात्रा का केवल एक हिस्सा है।
उन स्थितियों को शामिल करें जो अनपेक्षित समस्याओं को उजागर करती हैं
मोबाइल क्लाइंट्स, IPv6 और Captive Portal सहित लोगों द्वारा उपयोग किए जाने वाले नेटवर्क और डिवाइसों के प्रकारों से परीक्षण करें। उन एप्लिकेशनों और ब्राउज़रों की जांच करें जो अपने स्वयं के DoH या DoT सेवा का चयन कर सकते हैं, क्योंकि वे DNS अनुरोधों के मार्ग और दृश्यता दोनों को बदल सकते हैं।
DoQ, DNS over QUIC, को डिस्ट्रीब्यूटेड मेजरमेंट्स में प्लेनटेक्स्ट परफॉरमेंस के करीब पहुंचते और DoH की तुलना में कुछ पेज-लोड मामलों में सुधार करते देखा गया है। इन निष्कर्षों को अपने परिवेश में ट्रांसपोर्ट विकल्पों का परीक्षण करने के कारण के रूप में देखें, न कि किसी विशेष परिणाम के वादे के रूप में। व्यावहारिक लक्ष्य एक पास का रिज़ॉल्वर, प्रभावी कैशिंग, पुन: प्रयोज्य एन्क्रिप्टेड सेशन और एक ऐसा डिज़ाइन है जो अनप्रबंधित पाथ को खुला न छोड़े।
वेन्यू और एंटरप्राइजेज में वास्तविक दुनिया के उपयोग के मामले
एक राष्ट्रीय परिनियोजन दिखाता है कि सुरक्षात्मक DNS तब क्या कर सकता है जब कई संगठन एक प्रबंधित सुरक्षा परत साझा करते हैं। यूनाइटेड किंगडम में, सुरक्षात्मक डोमेन नेम सिस्टम सेवा का उपयोग करने वाले संगठनों की संख्या 2022 में 944 से बढ़कर 1,173 हो गई, जो 24% की वृद्धि है। उस पूरे वर्ष में, सेवा ने लगभग 0.55 ट्रिलियन DNS प्रश्नों को प्रोसेस किया और दुर्भावनापूर्ण गंतव्यों से जुड़े 11 बिलियन अनुरोधों को ब्लॉक किया, जो सभी प्रश्नों का लगभग 2% है (UK NCSC PDNS सारांश)।
वह पैमाना कनेक्शन का प्रयास करने से पहले निर्णय लेने के मूल्य को दर्शाता है। यह साबित नहीं करता है कि प्रत्येक ब्लॉक किया गया अनुरोध एक घटना बन जाता, या केवल DNS ने ही खतरे के हर रास्ते को रोक दिया। एक मल्टी-साइट ऑपरेटर के लिए, उपयोगी तुलना यह है कि क्या सेवा नीति को लगातार लागू कर सकती है, कार्रवाई योग्य टेलीमेट्री तैयार कर सकती है, और उस परिवेश के वॉल्यूम और अपवादों को संभाल सकती है।
विचार करें कि एक ही चेकपॉइंट अलग - अलग वेन्यू में कैसे फिट बैठता है:
- होटल और आवासीय संपत्तियां: अतिथि या निवासी की पहुंच को कर्मचारियों और भवन के उपकरणों से अलग करें। एक Captive Portal, एक पुराना उपकरण, या एक निवासी का पसंदीदा एन्क्रिप्टेड रिज़ॉल्वर योजना बनाने के लिए एक अपवाद बना सकता है।
- हवाई अड्डे और स्टेडियम: परिचालन और कर्मचारियों के नेटवर्क को अलग रखते हुए उच्च-टर्नओवर सार्वजनिक पहुंच में एक सामान्य आधार रेखा लागू करें। अप्रबंधित उपकरणों और कनेक्टिविटी आवश्यकताओं पर नज़र रखें जिनके लिए दस्तावेजी अपवाद की आवश्यकता होती है।
- स्वास्थ्य सेवा और शिक्षा: देखभाल, शिक्षण या प्रशासन के लिए उपयोग की जाने वाली वैध सेवाओं को ब्लॉक किए बिना हानिकारक गंतव्यों तक पहुंच को प्रतिबंधित करें। जब कोई नीति कार्य के लिए आवश्यक किसी चीज़ को ब्लॉक करती है तो एक स्पष्ट समीक्षा मार्ग प्रदान करें।
- रिटेल और शॉपिंग सेंटर: विज़िटर ट्रैफ़िक को टिल, स्टाफ डिवाइस और अन्य परिचालन उपकरणों से अलग करें। जब पहुंच और नीति कैसे एक साथ फिट होती है, इस पर विचार कर रहे हों, तो अतिथि पहुंच की योजना बनाने वाली रिटेल टीमें इन रिटेल WiFi समाधानों को भी उपयोगी पा सकती हैं।
विषय का एक छोटा परिचय टीमों को यह समझने में भी मदद कर सकता है कि DNS लेयर क्या करती है और क्या नहीं करती है:
प्रत्येक सेटिंग में, DNS फ़िल्टरिंग एक आंशिक नियंत्रण है, यह गारंटी नहीं है कि हर खतरा रुक जाएगा। एक उपयोगकर्ता किसी अन्य रिज़ॉल्वर या सीधे IP एड्रेस के माध्यम से इंफ्रास्ट्रक्चर तक पहुंच सकता है, और एक एप्लिकेशन ऐसे प्रोटोकॉल का उपयोग कर सकता है जो संगठन के DNS पाथ पर निर्भर नहीं करते हैं। परिनियोजन में नीति के साथ-साथ अपवाद हैंडलिंग और मॉनिटरिंग की आवश्यकता होती है।
अपने नेटवर्क के लिए सही दृष्टिकोण चुनना
सुरक्षात्मक DNS रिस हल करने वाले (resolver) पर काम करता है। एंडपॉइंट एजेंट, ब्राउज़र सेटिंग्स और नेटवर्क नियंत्रण अलग-अलग बिंदुओं पर काम करते हैं, इसलिए टीमें आमतौर पर एक एकल विकल्प के बजाय एक संयोजन चुनती हैं। सही मिश्रण इस बात पर निर्भर करता है कि डिवाइस का प्रबंधन कौन करता है, नेटवर्क किस ट्रैफिक को देख सकता है, और अपवादों को कैसे संभाला जाना चाहिए।
| नियंत्रण | सबसे उपयुक्त | दृश्यता | सामान्य सीमा |
|---|---|---|---|
| Protective DNS | साझा नेटवर्क, प्रबंधित संपत्ति, और DNS-नीति प्रवर्तन | DNS अनुरोध जो हलकर्ता (resolver) से गुजरते हैं | गैर-प्रबंधित हलकर्ता और गैर-DNS मार्ग इसे बायपास कर सकते हैं |
| Endpoint एजेंट | प्रबंधित लैपटॉप और मोबाइल उपकरण जिन्हें नेटवर्क से बाहर सुरक्षा की आवश्यकता होती है | स्थापित एजेंट को दिखाई देने वाली गतिविधि | कवरेज एजेंट स्थापना, स्वास्थ्य और प्रबंधन पर निर्भर करती है |
| Browser नीति | प्रबंधित ब्राउज़र जहाँ हलकर्ता और ब्राउज़िंग सेटिंग्स को नियंत्रित किया जा सकता है | ब्राउज़र कॉन्फ़िगरेशन और चयनित ब्राउज़र गतिविधि | हर ऐप या गैर-प्रबंधित ब्राउज़र को नियंत्रित नहीं करता है |
| नेटवर्क-स्तरीय नियंत्रण | विभाजित नेटवर्क और ट्रैफ़िक जो प्रबंधित इंफ्रास्ट्रक्चर के माध्यम से गुजरता है | नियंत्रण के कवरेज के भीतर नेटवर्क प्रवाह | एंक्रिप्टेड या नेटवर्क से बाहर का ट्रैफ़िक निरीक्षण को सीमित कर सकता है |
| पहचान और पहुंच नियंत्रण | कर्मचारी, अतिथि, निवासी, और विशिष्ट पहुंच आवश्यकताओं वाले डिवाइस समूह | पहचान या खंड से जुड़े कनेक्शन और पहुंच के निर्णय | एक अनुमति प्राप्त कनेक्शन स्वयं हर गंतव्य का न्याय नहीं करता है |
प्रबंधित लैपटॉप के लिए, एंडपॉइंट और ब्राउज़र कंट्रोल रिज़ॉल्वर नीति को पूरा कर सकते हैं, विशेष रूप से तब जब कर्मचारी कार्यालय से दूर काम करते हैं। गेस्ट WiFi और BYOD को एजेंटों के साथ प्रबंधित करना अधिक कठिन है, जिससे नेटवर्क-साइड कंट्रोल अधिक व्यावहारिक हो जाते हैं, बशर्ते संगठन DNS को अपनी चुनी हुई सेवा के लिए निर्देशित कर सके। IoT और आवासीय उपकरणों को अक्सर सेगमेंटेशन और एक ऐसी नीति की आवश्यकता होती है जो सीमित डिवाइस-मैनेजमेंट विकल्पों का ध्यान रखती हो।
नेटवर्क पहचान, फ़िल्टरिंग और उपयोगकर्ता-सामना करने वाले चेक की तुलना करने वाली टीमों के लिए, mailX से मुफ़्त DNS और ईमेल चेक पहुंच नियंत्रण की व्यापक समीक्षा के साथ एक प्रासंगिक संसाधन हो सकता है। यदि भुगतान वातावरण संपत्ति का हिस्सा हैं, तो इस बात पर भी विचार करें कि WiFi डिज़ाइन और PCI-DSS अनुपालन आवश्यकताएं नेटवर्क पृथक्करण और प्रशासन को कैसे प्रभावित करती हैं।
Purple Access मौजूदा एक्सेस पॉइंट्स पर ओपन, सुरक्षित और xPSK नेटवर्क विकल्पों को कैप्टिव पोर्टल ऑनबोर्डिंग और पहचान-संचालित नेटवर्क असाइनमेंट के साथ जोड़ता है। Purple Shield प्रति-नीति नियंत्रणों के साथ सुरक्षात्मक DNS और सामग्री फ़िल्टरिंग जोड़ता है। वे क्षमताएं एंडपॉइंट और ब्राउज़र नियंत्रणों के साथ मौजूद हो सकती हैं, लेकिन वे रिज़ॉल्वर प्रवर्तन, अपवादों और निगरानी को परिभाषित करने की आवश्यकता को समाप्त नहीं करती हैं। उन मार्गों और उपकरणों के अनुसार टूल चुनें जिन्हें आपको सुरक्षित करने की आवश्यकता है, फिर सत्यापित करें कि उनकी नीतियां एक साथ काम करती हैं।
ब्लॉक की गई संख्याओं से परे प्रोटेक्टिव DNS मूल्य को मापना
ब्लॉक की गई - क्वेरी की कुल संख्या आपको बताती है कि रिज़ॉल्वर ने कार्रवाई की है। अपने आप में, यह आपको यह नहीं बताता है कि क्या इसने सही अनुरोधों को पकड़ा, उपयोगी काम को बाधित किया, या दूसरा रास्ता चुनने वाले ट्रैफ़िक को छोड़ दिया। निर्णय को गिनें, लेकिन नियंत्रण को मापें।
यूरोपीय इंटरनेट उद्योग संघ की DNS कार्यशाला ने पिछले छह महीनों के दौरान 780,000 विशिष्ट डोमेन को कवर करने वाली 2.3 मिलियन दुरुपयोग रिपोर्टों दर्ज कीं, जिनमें मासिक रिपोर्ट 220,000 से बढ़कर 380,000 हो गईं (कार्यशाला रिपोर्ट)। वे आंकड़े रिपोर्ट किए गए दुरुपयोग के पैमाने को दर्शाते हैं। वे यह स्थापित नहीं करते हैं कि रिज़ॉल्वर ने कितनी घटनाओं को रोका, क्या कोई ब्लॉक सही था, या क्या प्रभावित ट्रैफ़िक VPN, एक वैकल्पिक रिज़ॉल्वर, एक हार्ड-कोडेड IP एड्रेस, या एक एन्क्रिप्टेड एप्लिकेशन प्रोटोकॉल के माध्यम से गंतव्य तक पहुंचा।
परिणामों और अपवादों के आधार पर एक स्कोरकार्ड बनाएं
एक उपयोगी समीक्षा सुरक्षा, सेवा की गुणवत्ता और परिचालन प्रतिक्रिया को जोड़ती है। ट्रैक करें कि क्या हलकर्ता (resolver) ने ज्ञात दुर्भावनापूर्ण डोमेन का पता लगाया, टीमें झूठे-सकारात्मक अपीलों को कितनी जल्दी संभालती हैं, और क्या नीति परिवर्तन लक्षित स्थानों तक तुरंत पहुंचते हैं। इन उपायों को हलकर्ता की उपलब्धता और औसत तथा टेल लुकअप विलंबता के साथ जोड़ें।
बायपास प्रयासों को भी मापें। ब्लॉक किए गए अनुरोधों की कम संख्या का अर्थ यह हो सकता है कि वातावरण में बहुत कम दुर्भावनापूर्ण गतिविधि है, या इसका अर्थ यह हो सकता है कि उपकरण सुरक्षात्मक रिसॉल्वर का उपयोग नहीं कर रहे हैं। प्रासंगिक घटनाओं को नेटवर्क पहचान से जोड़ें, जैसे कि SSID, VLAN, स्थल, या उपयोगकर्ता समूह, ताकि जांचकर्ता देख सकें कि नीति कहां लागू होती है और अपवाद कहां छिपा हो सकता है। प्रत्येक अवरुद्ध लुकअप को रोकी गई घटना मानने के बजाय DNS गतिविधि की तुलना एंडपॉइंट या घटना डेटा से करें।
DNS लॉग को संवेदनशील परिचालन डेटा के रूप में समझें
DNS लॉग ब्राउज़िंग पैटर्न को उजागर कर सकते हैं, जिसके लिए स्वास्थ्य सेवा, शिक्षा, आतिथ्य और आवासीय परिवेश में देखभाल की आवश्यकता होती है। अवधारण सीमाएं निर्धारित करें, भूमिका द्वारा पहुंच को प्रतिबंधित करें, और सुरक्षा टेलीमेट्री को गेस्ट-मार्केटिंग डेटा से अलग रखें। बड़े पैमाने पर लॉग एकत्र करने से पहले यह तय करें कि सुरक्षा घटना की जांच कौन कर सकता है और उन्हें किस डेटा की आवश्यकता है।
अपने प्रोटेक्टिव DNS रोलआउट की योजना बनाने के लिए अगले कदम
डैशबोर्ड से नहीं, बल्कि पथ से शुरुआत करें। मैप करें कि कौन से उपकरण प्रबंधित हलकर्ता (resolver) का उपयोग करते हैं, पहचानें कि प्रत्यक्ष DNS या अनधिकृत एन्क्रिप्टेड DNS इसे कहाँ बायपास कर सकते हैं, और यह तय करें कि संगठन द्वारा प्रबंधित न किए जाने वाले उपकरणों के लिए प्रवर्तन कैसे काम करेगा। वैध सेवाओं के लिए एक अपवाद प्रक्रिया शामिल करें जिन्हें कोई नीति ब्लॉक करती है।
रोलआउट से पहले, इस बात पर सहमति बनाएं कि टीम सुरक्षा और सेवा गुणवत्ता दोनों का आकलन कैसे करेगी:
- हलकर्ता (resolver) उपयोग की पुष्टि करें: प्रबंधित डिवाइस, गेस्ट नेटवर्क, और IoT जैसे कम अनुमानित डिवाइस की जाँच करें।
- नेटवर्क पथ का परीक्षण करें: जहाँ प्रवर्तन आवश्यक है, प्रत्यक्ष DNS और अनधिकृत एंक्रिप्टेड-DNS मार्गों की समीक्षा करें।
- प्रदर्शन मापें: धीमी प्रतिशतता सहित कोल्ड- और वार्म-कैश लुकअप विलंबता की तुलना करें।
- स्कोरकार्ड परिभाषित करें: गलत-सकारात्मक प्रबंधन, उपलब्धता, नीति प्रसार, बायपास प्रयासों और घटना के परिणामों को ट्रैक करें।
- गोपनीयता नियम निर्धारित करें: व्यापक संग्रह शुरू होने से पहले लॉग एक्सेस और रिटेंशन सीमाएं स्थापित करें।
मल्टी-साइट परिनियोजन के लिए, पहचानों, नेटवर्क खंडों, रिसॉल्वर मार्गों और प्रत्येक स्थान के लिए आवश्यक अपवादों का मानचित्रण करने के लिए नेटवर्क और सुरक्षा टीमों को एक साथ लाएं। Purple परिनियोजन योजनाओं को आकार देने और सत्यापित करने के लिए नेटवर्क इंजीनियरों के नेतृत्व में डिज़ाइन सत्र प्रदान करता है। सुरक्षात्मक DNS प्रबंधित लुकअप पथ के माध्यम से हानिकारक गंतव्यों तक पहुंचना कठिन बना सकता है, लेकिन यह एंडपॉइंट सुरक्षा, नेटवर्क विभाजन, या गोपनीयता प्रशासन को प्रतिस्थापित नहीं करेगा।
Purple Access खुले, सुरक्षित और xPSK WiFi नेटवर्क का समर्थन करता है, जिसमें मौजूदा एक्सेस पॉइंट्स पर पहचान-आधारित नेटवर्क असाइनमेंट और अतिथि या BYOD ऑनबोर्डिंग की सुविधा शामिल है। यह योजना बनाने के लिए कि ये एक्सेस कंट्रोल आपकी साइटों पर सुरक्षात्मक DNS के साथ मिलकर कैसे काम कर सकते हैं, Purple Access पर जाएं।
