MSP और बहु-साइट संपत्तियों के लिए DNS फ़िल्टरिंग

MSPs और बहु-साइट संपत्तियों के लिए DNS फ़िल्टरिंग डिवाइस के कनेक्ट होने से पहले क्लाउड में सुरक्षा नीतियों के विरुद्ध डोमेन अनुरोधों की जांच करती है। SSIDs, Captive Portals और एनालिटिक्स के साथ Purple के माध्यम से केंद्रीय रूप से प्रबंधित, इसके लिए साइट पर किसी हार्डवेयर की आवश्यकता नहीं होती है। Cisco Meraki और HPE Aruba जैसे एकीकरणों में काम करते हुए, Purple बिना किसी एजेंट के 80,000+ से अधिक लाइव स्थलों में फैले नेटवर्क संपत्तियों की सुरक्षा करता है।

MSPs और बहु-साइट संपत्तियों के लिए DNS फ़िल्टरिंग क्या है?

कोई भी डिवाइस जो कनेक्शन बनाता है, उसकी शुरुआत DNS (डोमेन नेम सिस्टम) लुकअप से होती है। डिवाइस एक हलकर्ता (resolver) से example.com जैसे नाम को IP पते में बदलने के लिए कहता है। DNS फ़िल्टरिंग, जिसे सुरक्षात्मक DNS भी कहा जाता है, उत्तर देने से पहले उस नाम की नीति के विरुद्ध जांच करती है। यदि डोमेन दुर्भावनापूर्ण या नीति के विरुद्ध है, तो हलकर्ता वास्तविक पता रोक लेता है। डिवाइस कभी भी कनेक्शन नहीं खोलता है, इसलिए कुछ भी डाउनलोड नहीं होता है और कोई पेज लोड नहीं होता है।

एक एकल स्थल के लिए, यह एक उपयोगी नियंत्रण है। एक प्रबंधित सेवा प्रदाता (MSP) या एक बहु-साइट IT टीम के लिए, आवश्यकता का रूप बदल जाता है। आप विभिन्न हार्डवेयर पर, विभिन्न नियमों के साथ, विभिन्न ग्राहकों के स्वामित्व वाले दर्जनों या सैकड़ों नेटवर्क को फ़िल्टर करते हैं। यह तीन आवश्यकताएं लाता है जो एक एकल-साइट फ़िल्टर शायद ही कभी पूरा करता है:

• प्रति-किराएदार (Per-tenant) नीति। एक किराएदार एक ग्राहक या व्यावसायिक इकाई है जिसके अपने नियम हैं। एक पारिवारिक होटल समूह, एक पब श्रृंखला और एक जीपी सर्जरी को कभी भी एक नीति साझा नहीं करनी चाहिए।
• केंद्रीय प्रबंधन। आपको प्रत्येक साइट पर लॉग इन किए बिना, एक ही स्थान से प्रत्येक किराएदार की नीति देखने और बदलने की आवश्यकता है।
• कोई प्रति-साइट हार्डवेयर नहीं। प्रत्येक स्थान पर एक उपकरण को शिपिंग, रैकिंग और पैचिंग करना पूरे बेड़े में संभव नहीं है।

Shield SecurePass और Verify के साथ Purple का सुरक्षात्मक-DNS ऐड-ऑन है। फ़िल्टरिंग क्लाउड में चलती है और SSIDs (नेटवर्क नाम), Captive Portals और एनालिटिक्स से जुड़ती है जिन्हें आप पहले से ही प्रत्येक ग्राहक के लिए प्रबंधित करते हैं। Captive Portal वह लॉगिन पृष्ठ है जिसे कोई विज़िटर ऑनलाइन होने से पहले देखता है।

ग्राहक साइटों के बेड़े में MSP फ़िल्टरिंग एकल-साइट परिनियोजन से कैसे भिन्न है

एक एकल-साइट फ़िल्टर में एक नीति, एक व्यवस्थापक और एक नेटवर्क होता है। एक MSP संपत्ति में एक पदानुक्रम होता है। आप संपत्ति के लिए नियम निर्धारित करते हैं, उन्हें प्रति ग्राहक ओवरराइड करते हैं, और फिर एक साइट के भीतर प्रति नेटवर्क उन्हें बदलते हैं। एक होटल के अतिथि नेटवर्क को रिसेप्शन के पीछे के कर्मचारी नेटवर्क से अलग नियमों की आवश्यकता होती है।

स्टैंडअलोन DNS फ़िल्टर आमतौर पर WiFi से अलग कॉन्फ़िगर किए गए, प्रति किराएदार एक उप-संगठन के साथ इसे संभालते हैं। आप प्रत्येक ग्राहक के लिए दो स्टैक चलाते हैं: एक नेटवर्क और पोर्टल के लिए, एक हलकर्ता के लिए। Shield दूसरे स्टैक को हटा देता है, क्योंकि फ़िल्टरिंग नीति उन्हीं नेटवर्क का अनुसरण करती है जिन्हें आपने Purple में पहले से परिभाषित किया है।

ग्राहक साइटों के पूरे बेड़े में DNS फ़िल्टरिंग क्यों महत्वपूर्ण है?

तीन दबाव फ़िल्टरिंग को MSP के एजेंडे में ऊपर ले जाते हैं: देखभाल का कर्तव्य, खतरे का जोखिम और सीमित बैंडविड्थ।

साझा नेटवर्क पर देखभाल का कर्तव्य

सार्वजनिक और गेस्ट WiFi वास्तविक जिम्मेदारियों के साथ आता है। इंग्लैंड में, स्कूल और कॉलेज 'Keeping children safe in education' में संदर्भित शिक्षा विभाग के फ़िल्टरिंग और मॉनिटरिंग मानकों का पालन करते हैं। US में, Children's Internet Protection Act (CIPA) के तहत E-rate फंडिंग प्राप्त करने वाले स्कूलों और पुस्तकालयों को फ़िल्टर करना आवश्यक है। परिवारों का स्वागत करने वाले होटल, कैफ़े और अवकाश केंद्र प्रतिष्ठा के जोखिम का सामना करते हैं यदि कोई बच्चा वयस्क सामग्री तक पहुँचता है। UK की Friendly WiFi योजना ठीक उसी कारण से मौजूद है।

जब आप 40 क्लाइंट्स के लिए WiFi चलाते हैं, तो आप प्रत्येक जिम्मेदारी का एक हिस्सा निभाते हैं। एक अनफ़िल्टर की गई साइट एक ऐसी क्लाइंट बातचीत है जो आप नहीं चाहते हैं।

वे खतरे जो अनप्रबंधित डिवाइसों तक पहुँचते हैं

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

Purple Shield DNS लुकअप चरण में ही खतरों को चिन्हित करता है, जिससे कनेक्शन पूरा होने से पहले ही दुर्भावनापूर्ण अनुरोध रुक जाते हैं। संपूर्ण बेड़े में, एक खतरे का ब्लॉक एक ही समय में प्रत्येक क्लाइंट साइट पर लागू होता है। बाज़ार के व्यापक दृष्टिकोण के लिए, Phishing Protection Software: 10 Options for Shared WiFi देखें।

सीमित साइटों पर बैंडविड्थ

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

फ़ायरवॉल से क्या छूट जाता है

फ़ायरवॉल अभी भी महत्वपूर्ण है, लेकिन यह एक अलग बिंदु पर काम करता है। यह DNS द्वारा उत्तर दिए जाने के बाद ही कनेक्शन का निरीक्षण करता है। इससे मल्टी-साइट गेस्ट संपत्ति पर चार कमियां रह जाती हैं:

1. एंक्रिप्शन गंतव्य को छिपा देता है। TLS 1.3 (RFC 8446) सर्वर प्रमाणपत्र को एन्क्रिप्ट करता है। Encrypted Client Hello (ECH), TLS का एक IETF विस्तार, सर्वर का नाम भी छिपा सकता है। एक्रिप्शन के बिना, एक फ़ायरवॉल को केवल एक IP एड्रेस दिखाई देता है और इसके अलावा कुछ खास नहीं, और आप किसी विज़िटर के डिवाइस पर एक्रिप्शन प्रमाणपत्र इंस्टॉल नहीं कर सकते।
2. साझा IP एड्रेस नियमों को धुंधला कर देते हैं। कंटेंट डिलीवरी नेटवर्क एक ही एड्रेस पर कई डोमेन होस्ट करते हैं। IP को ब्लॉक करें और आप वैध साइटों को बाधित कर देंगे; इसे अनुमति दें और खराब डोमेन आगे निकल जाता है।
3. प्रति-साइट नियम समूह भटक जाते हैं। वर्षों में निर्मित एक बेड़ा फ़ायरवॉल विक्रेताओं और फर्मवेयर संस्करणों को मिश्रित करता है। 60 नियम सेटों को संरेखित रखना एक पूर्णकालिक काम है, और एक भूली हुई साइट ही कमी बन जाती है।
4. ब्लॉक देर से आता है। जब तक फ़ायरवॉल कार्रवाई करता है, तब तक डिवाइस नाम का समाधान कर चुका होता है और कनेक्शन का प्रयास कर चुका होता है। DNS फ़िल्टरिंग कोई भी कनेक्शन बनने से पहले ही अनुरोध को रोक देती है।

DNS फ़िल्टरिंग बिना किसी एक्रिप्शन, एजेंट या प्रति-साइट नियमों के इन कमियों को दूर करती है। यह नेटवर्क को विभाजित करने और पोर्ट को नियंत्रित करने के फ़ायरवॉल के काम को प्रतिस्थापित नहीं करती है।

कई टेनेंट्स में DNS फ़िल्टरिंग कैसे काम करती है?

प्रत्येक लुकअप के दौरान क्या होता है

1. एक अतिथि क्लाइंट के WiFi से जुड़ता है, अक्सर एक Captive Portal के माध्यम से।
2. डिवाइस एक डोमेन का अनुरोध करता है, उदाहरण के लिए फ़िशिंग ईमेल में किसी लिंक से।
3. Shield उस नेटवर्क को असाइन की गई पॉलिसी के विरुद्ध डोमेन की जाँच करता है।
4. यदि डोमेन की अनुमति है, तो डिवाइस को एड्रेस प्राप्त होता है और वह सामान्य रूप से कनेक्ट हो जाता है।
5. यदि यह ब्लॉक है, तो लुकअप वास्तविक एड्रेस वापस नहीं करता है, इसलिए कोई कनेक्शन नहीं खुलता है।

प्रति-टेनेंट पॉलिसी की संरचना कैसे करें

प्रति-टेनेंट कंटेंट फ़िल्टरिंग मानक पॉलिसियों के एक छोटे सेट के रूप में सबसे अच्छा काम करती है, न कि प्रति साइट एक बेस्पोक नियम सेट के रूप में। यह पैटर्न हॉस्पिटैलिटी, रिटेल और सार्वजनिक क्षेत्र में समान रूप से उपयोगी है:

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

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

क्योंकि Shield पॉलिसियों को उन नेटवर्क से जोड़ता है जिन्हें आप Purple में चलाते हैं, एक साइट की गेस्ट और स्टाफ SSID अलग-अलग पॉलिसियों को ले जा सकती हैं। IEEE 802.1X का उपयोग करने वाले स्टाफ नेटवर्क, जो पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल के लिए मानक है, अपने पहचान नियंत्रण को बनाए रखते हैं। Shield इसके ऊपर DNS लेयर जोड़ता है।

एक ही डैशबोर्ड से बेड़े का प्रबंधन करना

सेंट्रल DNS पॉलिसी प्रबंधन का लाभ केवल तभी मिलता है जब यह आपके काम करने के तरीके से मेल खाता हो। Shield उसी Purple प्लेटफ़ॉर्म में मौजूद है जो प्रत्येक क्लाइंट के SSID, Captive Portal और एनालिटिक्स को चलाता है। फ़िल्टर बदलने के लिए आपको कंसोल बदलने की आवश्यकता नहीं होती है, और आपको दूसरी साइट इन्वेंट्री बनाए रखने की आवश्यकता नहीं होती है।

एक MSP के लिए इसके व्यावहारिक परिणाम हैं:

• ऑनबोर्डिंग। Purple में एक नए क्लाइंट साइट को किसी अलग रिज़ॉल्वर खाते की आवश्यकता नहीं है।
• बदलाव नियंत्रण। एक बार पॉलिसी बदलें और यह इसे असाइन किए गए प्रत्येक नेटवर्क पर लागू होती है।
• रिपोर्टिंग। फ़िल्टरिंग गतिविधि आपके द्वारा पहले से साझा किए जाने वाले कनेक्शन एनालिटिक्स के साथ बैठती है, इसलिए एक त्रैमासिक समीक्षा में WiFi और सुरक्षा दोनों शामिल होते हैं।

शिप करने के लिए कुछ भी क्यों नहीं है

Shield क्लाउड में फ़िल्टर करता है, इसलिए प्रत्येक स्थान पर खरीदने, कॉन्फ़िगर करने, शिप करने या बदलने के लिए कोई उपकरण नहीं है। Purple हार्डवेयर-अज्ञेयवादी (hardware-agnostic) है और Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet पर क्लाउड ओवरले के रूप में चलता है। एक क्लाइंट एस्टेट जो अधिग्रहण के बाद विक्रेताओं को मिलाता है, फिर भी पॉलिसियों का एक सेट चलाता है। सेटअप विक्रेता के अनुसार भिन्न होता है, इसलिए अपने हार्डवेयर के लिए Purple के सहायता दस्तावेज़ों का पालन करें।

Purple पहले से ही 80,000+ से अधिक लाइव स्थानों पर चलता है और 2024 में 440 मिलियन लॉगिन दर्ज किए गए हैं (Purple डेटा)।

एक वास्तविक एस्टेट पर DNS फ़िल्टरिंग कैसी दिखती है?

नीचे दिए गए तीन परिदृश्य सामान्य एस्टेट आकृतियों से बने मिश्रित उदाहरण हैं। साइटों की संख्या और हार्डवेयर विशिष्ट हैं; परिणाम प्रत्येक परिवर्तन के परिचालन अंकगणित हैं।

परिदृश्य 1: 14 हॉस्पिटैलिटी क्लाइंट्स वाला एक MSP

स्थिति। एक MSP 60 साइटों पर 14 हॉस्पिटैलिटी क्लाइंट्स के लिए गेस्ट और स्टाफ WiFi संचालित करता है। इसमें स्वतंत्र होटल, 20-साइट वाला एक पब समूह और एक हॉलिडे पार्क शामिल हैं। WiFi और captive portals पहले से ही Purple पर चलते हैं। फ़िल्टरिंग एक अलग DNS सेवा पर चलती थी, जिसमें प्रति क्लाइंट एक खाता और साइट सूची थी।

क्या किया गया। MSP ने फ़िल्टरिंग को Shield में स्थानांतरित कर दिया और 14 बेस्पोक नियम सेटों को चार मानक नीतियों से बदल दिया। फैमिली होटलों और हॉलिडे पार्क ने फैमिली गेस्ट को अपनाया; पब समूह ने एडल्ट गेस्ट को अपनाया। दो क्लाइंट्स ने छोटी अपवाद सूचियां रखीं।

परिणाम। 60 साइटों पर शून्य हार्डवेयर शिप किया गया और शून्य साइट विजिट हुई। MSP ने 14 अलग फ़िल्टरिंग खातों को बंद कर दिया और अब प्रत्येक क्लाइंट को उसी Purple डैशबोर्ड से प्रबंधित करता है जिसका वह पहले से उपयोग कर रहा था। नियम परिवर्तन का अर्थ चार नीतियों में से एक को संपादित करना है, न कि 60 साइट प्रविष्टियों तक को।

परिदृश्य 2: एक परिषद के पुस्तकालय और अवकाश केंद्र

स्थिति। एक काउंटी परिषद 22 पुस्तकालयों और पांच अवकाश केंद्रों में सार्वजनिक WiFi प्रदान करती है। बच्चे स्कूल के बाद पुस्तकालय नेटवर्क का उपयोग करते हैं। दो खरीद दौरों के बाद पुस्तकालयों में HPE Aruba और अवकाश केंद्रों में Ubiquiti UniFi रह गया। आईटी टीम तीन लोगों की है।

क्या किया गया। परिषद ने प्रत्येक सार्वजनिक SSID पर फैमिली गेस्ट और स्टाफ नेटवर्क पर स्टाफ नीति लागू की। स्टाफ प्रमाणीकरण 802.1X पर WPA3-Enterprise के साथ रहता है, जो वर्तमान एंटरप्राइज WiFi एन्क्रिप्शन मानक है। विज़िटर अभी भी परिषद के captive portal के माध्यम से जुड़ते हैं।

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

परिदृश्य 3: सीमित बैकहॉल पर 120-स्टोर वाला रिटेलर

स्थिति। एक रिटेलर 120 स्टोरों में खरीदारों के लिए गेस्ट WiFi चलाता है, जिनमें से एक तिहाई 4G बैकहॉल पर हैं। शॉपर ब्राउज़िंग बैंडविड्थ के लिए स्टोर सिस्टम के साथ प्रतिस्पर्धा करती है। कार्डधारक डेटा वातावरण को PCI DSS दायरे से बाहर रखने के लिए पहले से ही गेस्ट ट्रैफ़िक से अलग किया गया है।

क्या किया गया। रिटेलर ने केवल गेस्ट SSID पर Shield की थ्रेट प्रोटेक्शन और एड ब्लॉकिंग को सक्षम किया। इसने अपनी सबसे व्यस्त 4G साइटों पर 10-स्टोर पायलट के साथ शुरुआत की। स्टाफ और स्टोर-सिस्टम नेटवर्क अपने स्वयं के सेगमेंट पर रहे।

परिणाम। पायलट ने चार हफ़्तों में उपयोग से पहले और बाद के अपने आंकड़ों को मापा, जिसने सीमित कनेक्शनों में कुल डेटा खपत में कमी का प्रदर्शन किया। इसके बाद रिटेलर ने बिना किसी स्टोर विजिट के, एक ही बदलाव में सभी 120 स्टोरों तक नीति का विस्तार किया।

आपके द्वारा पहले से चलाए जा रहे सिस्टम के साथ DNS फ़िल्टरिंग कहां स्थित है?

सुरक्षात्मक DNS एक परत है। यह उन नियंत्रणों के साथ सबसे अच्छा काम करता है जो आपके पास पहले से मौजूद हैं।

• सेगमेंटेशन. VLANs (वर्चुअल LANs, जो एक भौतिक नेटवर्क को अलग-अलग लॉजिकल नेटवर्क में विभाजित करते हैं) गेस्ट ट्रैफिक को कर्मचारियों और भुगतान प्रणालियों से दूर रखते हैं। देखें गेस्ट और कर्मचारियों के लिए नेटवर्क सेगमेंटेशन कैसे सेट करें।
• ऑथेंटिकेशन. RADIUS के साथ 802.1X, वह प्रोटोकॉल जो सेंट्रल सर्वर के खिलाफ क्रेडेंशियल्स की जांच करता है, यह तय करता है कि स्टाफ नेटवर्क में कौन शामिल होगा। Microsoft Entra ID, Okta या Google Workspace के साथ SecurePass भी यही काम करता है। कनेक्ट होने के बाद डिवाइस कहां जा सकते हैं, यह Shield तय करता है।
• फायरवॉल. आपका फायरवॉल अभी भी सेगमेंट के बीच पोर्ट, प्रोटोकॉल और ट्रैफिक को नियंत्रित करता है। Shield लुकअप पर ही ज्ञात दुर्भावनापूर्ण गंतव्यों को रोकता है।
• गोपनीयता कानून. DNS लॉग में IP एड्रेस और डिवाइस आइडेंटिफायर हो सकते हैं, जिन्हें GDPR व्यक्तिगत डेटा मानता है। Purple GDPR अनुपालन करता है और ISO 27001 प्रमाणित है।

Shield की तुलना DNSFilter और Cisco Umbrella से कैसे की जाती है

DNSFilter और WebTitan MSPs को भारी लक्ष्य बनाते हैं, और Cisco Umbrella कई Cisco संपत्तियों में डिफॉल्ट है। सभी क्लाउड में DNS लेयर पर फ़िल्टर करते हैं। अंतर इसमें है कि कौन क्या और कहां प्रबंधित करता है।

मापदंड	Purple Shield	DNSFilter	Cisco Umbrella
फ़िल्टरिंग कहां होती है	DNS लुकअप, Purple के क्लाउड में	DNS लुकअप, DNSFilter के क्लाउड में	DNS लुकअप, Cisco के क्लाउड में
प्रति-साइट हार्डवेयर	कोई नहीं	नेटवर्क फ़िल्टरिंग के लिए कोई नहीं	DNS-लेयर सुरक्षा के लिए कोई नहीं
टैनेंट प्रबंधन	क्लाइंट WiFi चलाने वाले Purple डैशबोर्ड के अंदर	सब-ऑर्गनाइजेशन के साथ अलग MSP कंसोल	अलग मल्टी-ऑर्ग या MSP कंसोल
SSIDs, Captive Portals और WiFi एनालिटिक्स से जुड़ा हुआ	हां, WiFi प्लेटफॉर्म के लिए मूल	नहीं, एक अलग स्टैक के रूप में कॉन्फ़िगर किया गया	Cisco Meraki के साथ एकीकृत, इसके अपने कंसोल में प्रबंधित
ऑफ-साइट रोमिंग डिवाइस	आपके द्वारा चलाए जाने वाले WiFi पर डिवाइसों के लिए निर्मित	रोमिंग क्लाइंट एजेंट	Cisco Secure Client रोमिंग मॉड्यूल
हार्डवेयर कवरेज	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet	कोई भी नेटवर्क जो अपने रिज़ॉल्वर को DNS फॉरवर्ड कर सकता है	कोई भी नेटवर्क जो अपने रिज़ॉल्वर को DNS फॉरवर्ड कर सकता है, Cisco के साथ सबसे गहरा
इसके लिए सबसे उपयुक्त	MSPs जिनके क्लाइंट का WiFi Purple पर चलता है	साइट पर और बाहर प्रबंधित एंडपॉइंट्स की सुरक्षा करने वाले MSPs	Cisco सुरक्षा पर मानकीकृत संपत्तियां

विकल्प वहां मजबूत हैं जहां Shield प्रतिस्पर्धा नहीं करता है। DNSFilter और Cisco Umbrella दोनों साइट से बाहर प्रबंधित लैपटॉप के लिए रोमिंग एजेंट प्रदान करते हैं। Umbrella Cisco के व्यापक सुरक्षा पोर्टफोलियो के अंदर भी बैठता है। TitanHQ का WebTitan MSPs के लिए एक मल्टी-टैनेंट क्लाउड फ़िल्टर भी प्रदान करता है। यदि आपके अनुबंध कॉर्पोरेट एंडपॉइंट्स को कवर करते हैं जहां भी वे यात्रा करते हैं, तो उनमें से एक उपयुक्त हो सकता है।

Shield का मामला अधिक केंद्रित है और WiFi-संचालित MSPs के लिए अधिक मजबूत है। यदि आप प्रत्येक क्लाइंट के SSIDs, Captive Portal और एनालिटिक्स को Purple में चलाते हैं, तो प्रति टेनेंट एक अलग रिज़ॉल्वर स्टैक ओवरहेड है। विस्तार से जानने के लिए, Shield vs DNSFilter: a protective DNS comparison for WiFi operators और Shield vs Cisco Umbrella: choosing protective DNS for guest WiFi पढ़ें।

DNS फ़िल्टरिंग की वे कौन सी सीमाएं हैं जिन्हें आपको जानना चाहिए?

DNS फ़िल्टरिंग एक कनेक्शन में केवल एक बिंदु पर काम करती है, और वही इसकी सीमाओं को तय करता है।

• एंक्रिप्टेड DNS इसे बायपास कर सकता है। DNS over HTTPS (DoH, RFC 8484) और DNS over TLS (DoT, RFC 7858) किसी डिवाइस को अपना रिज़ॉल्वर स्वयं चुनने की अनुमति देते हैं। नेटवर्क नियंत्रण अनमनोज्ड डिवाइसों पर इसे कम कर सकते हैं लेकिन समाप्त नहीं कर सकते। DNS over HTTPS explained: privacy vs public WiFi filtering देखें।
• VPN इसके पार टनल बनाते हैं। पर्सनल VPN पर एक गेस्ट टनल के भीतर ही नाम रिज़ॉल्व करता है। आप ज्ञात VPN डोमेन को ब्लॉक कर सकते हैं, हर एक को नहीं।
• डायरेक्ट IP कनेक्शन DNS को छोड़ देते हैं। हार्ड-कोडेड IP एड्रेस को कॉल करने वाला मालवेयर कभी भी लुकअप नहीं करता है। आपका फ़ायरवॉल उस मामले को कवर करता है।
• यह डोमेन देखता है, कंटेंट नहीं। DNS फ़िल्टरिंग पूरे डोमेन को अनुमति देती है या ब्लॉक करती है, व्यक्तिगत पेजों या फाइलों को नहीं।
• श्रेणियों की समीक्षा आवश्यक है। कोई भी श्रेणी सूची कभी-कभी अधिक ब्लॉक या कम ब्लॉक कर सकती है। प्रत्येक क्लाइंट को एक नामित संपर्क और परिवर्तन का अनुरोध करने का मार्ग प्रदान करें।
• लॉग के लिए प्रशासन की आवश्यकता है। रोलआउट से पहले प्रति क्लाइंट रिटेंशन और एक्सेस पर सहमति व्यक्त करें, और इसे अपने डेटा प्रोसेसिंग समझौते में दर्ज करें।

आपको आगे क्या करना चाहिए?

1. अपने टेनेंट्स का मानचित्रण करें। प्रत्येक क्लाइंट, साइट और नेटवर्क को सूचीबद्ध करें, साथ ही वर्टिकल और नियामक कर्तव्यों जैसे कि स्कूल, पुस्तकालय, स्वास्थ्य सेवा और लाइसेंस प्राप्त स्थानों को भी शामिल करें।
2. मानक नीतियों का मसौदा तैयार करें। ऊपर दी गई चार नीतियों के साथ शुरुआत करें और सुरक्षा आधार रेखा को अनिवार्य रखें।
3. प्रतिनिधि साइटों पर पायलट करें। प्रति वर्टिकल एक साइट चुनें, जिसमें सीमित बैकहॉल वाली एक साइट भी शामिल हो, और पहले और बाद के डेटा उपयोग को मापें।
4. साइट के बजाय नीति द्वारा रोल आउट करें। प्रत्येक क्लाइंट के लिए नेटवर्क पर नीतियां असाइन करें, फिर 30 दिनों के बाद अपवादों की समीक्षा करें।
5. रिपोर्ट वापस दें। आपके द्वारा पहले से दिए जा रहे WiFi समीक्षाओं में फ़िल्टरिंग गतिविधि जोड़ें।

यदि आपके क्लाइंट्स का WiFi अभी तक Purple पर नहीं चलता है, तो Guest WiFi से शुरुआत करें, फिर Shield जोड़ें। पूरे एस्टेट में नेटवर्क सुरक्षित करने के बारे में अधिक जानकारी के लिए, All guides ब्राउज़ करें।

अक्सर पूछे जाने वाले प्रश्न

क्या मुझे DNS फ़िल्टरिंग का उपयोग करने के लिए प्रत्येक क्लाइंट साइट पर हार्डवेयर इंस्टॉल करने की आवश्यकता है?

नहीं। Shield क्लाउड में DNS लेयर पर फ़िल्टर करता है, इसलिए किसी भी स्थान पर खरीदने, कॉन्फ़िगर करने या शिप करने के लिए कोई उपकरण नहीं है। Purple आपके क्लाइंट्स के पास पहले से मौजूद एक्सेस पॉइंट्स पर क्लाउड ओवरले के रूप में चलता है, जिसमें Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet शामिल हैं। सेटअप विक्रेता के अनुसार भिन्न होता है, इसलिए अपने एस्टेट में प्रत्येक हार्डवेयर प्रकार के लिए Purple के सहायता दस्तावेज़ों का पालन करें।

क्या मैं प्रत्येक क्लाइंट और प्रत्येक नेटवर्क के लिए अलग-अलग फ़िल्टरिंग नीतियां सेट कर सकता हूं?

हाँ। Shield फ़िल्टरिंग नीति को उन नेटवर्क से जोड़ता है जिन्हें आप पहले से Purple में चलाते हैं, इसलिए प्रत्येक क्लाइंट और साइट के भीतर प्रत्येक SSID की अपनी नीति हो सकती है। एक होटल का गेस्ट नेटवर्क एडल्ट कंटेंट को ब्लॉक कर सकता है जबकि उसका स्टाफ नेटवर्क क्लाइंट के स्वीकार्य उपयोग नियमों को लागू करता है। प्रति साइट बेस्पोक नियमों की तुलना में मानक नीतियों का एक छोटा सेट, साथ ही छोटी अपवाद सूचियां, ऑडिट करने में आसान होती हैं।

क्या मैं एक ही डैशबोर्ड से कई साइटों के लिए कंटेंट फ़िल्टरिंग प्रबंधित कर सकता हूं?

हाँ। Shield को उसी Purple प्लेटफ़ॉर्म में प्रबंधित किया जाता है जो आपके क्लाइंट्स के SSIDs, कैप्टिव पोर्टल्स और एनालिटिक्स को चलाता है, इसलिए आप कंसोल बदले बिना फ़िल्टरिंग बदल सकते हैं। नीति में बदलाव उस नीति को सौंपे गए प्रत्येक नेटवर्क पर, हर साइट पर लागू होता है। फ़िल्टरिंग गतिविधि आपके मौजूदा WiFi रिपोर्टिंग के साथ रहती है, इसलिए एक क्लाइंट समीक्षा कनेक्टिविटी और सुरक्षा दोनों को एक साथ कवर करती है।

किसी MSP के लिए Shield की तुलना DNSFilter से कैसे की जाती है?

Shield उन MSPs के लिए उपयुक्त है जिनके क्लाइंट्स का WiFi पहले से ही Purple पर चलता है, जबकि DNSFilter उन MSPs के लिए उपयुक्त है जो साइट पर और बाहर प्रबंधित लैपटॉप की सुरक्षा करते हैं। दोनों बिना किसी प्रति-साइट हार्डवेयर के क्लाउड में DNS परत पर फ़िल्टर करते हैं। DNSFilter रोमिंग एजेंट के साथ एक अलग मल्टी-टेनेंट कंसोल के रूप में चलता है। Shield WiFi प्लेटफ़ॉर्म के अंदर चलता है, जो उन्हीं SSIDs, कैप्टिव पोर्टल्स और एनालिटिक्स से जुड़ा होता है जिन्हें आप पहले से प्रबंधित करते हैं।

क्या गेस्ट DNS over HTTPS या VPN के साथ DNS फ़िल्टरिंग को बायपास कर सकते हैं?

हाँ, एक दृढ़ संकल्प वाला गेस्ट ऐसा कर सकता है। DNS over HTTPS, DNS over TLS और व्यक्तिगत VPNs आपके हलकर्ता (रिफॉल्वर) के बाहर लुकअप भेजते हैं। नेटवर्क नियंत्रण इसे कम कर सकते हैं, उदाहरण के लिए ज्ञात VPN और सार्वजनिक DoH एंडपॉइंट्स को ब्लॉक करके, लेकिन कोई भी DNS फ़िल्टर पूरी तरह से अप्रबंधित डिवाइस को नियंत्रित नहीं करता है। नेटवर्क के DNS का उपयोग करने वाले प्रत्येक डिवाइस के लिए सेगमेंटेशन और अपने फ़ायरवॉल के साथ-साथ DNS फ़िल्टरिंग को डिफ़ॉल्ट सुरक्षा के रूप में मानें।

क्या DNS फ़िल्टरिंग स्कूलों और पुस्तकालयों को फ़िल्टरिंग आवश्यकताओं को पूरा करने में मदद करती है?

यह फ़िल्टरिंग तत्व को कवर करता है, लेकिन केवल फ़िल्टरिंग ही पूरी आवश्यकता को पूरा नहीं करती है। इंग्लैंड में, शिक्षा विभाग के फ़िल्टरिंग और निगरानी मानकों में नामित जिम्मेदारियों और नियमित समीक्षा के साथ फ़िल्टरिंग और निगरानी दोनों की अपेक्षा की जाती है। अमेरिका में, CIPA को E-rate वित्त पोषित स्कूलों और पुस्तकालयों की आवश्यकता होती है कि वे इंटरनेट सुरक्षा नीति के भीतर प्रौद्योगिकी सुरक्षा उपायों का उपयोग करें। अपनी निगरानी और सुरक्षा प्रक्रियाओं के साथ साइटों पर लगातार फ़िल्टरिंग को जोड़ें।

GDPR के तहत DNS क्वेरी लॉग को कैसे संभाला जाता है?

Purple GDPR का अनुपालन करता है और इसके पास ISO 27001 प्रमाणन है। DNS लॉग में IP एड्रेस और डिवाइस पहचानकर्ता शामिल हो सकते हैं, जिन्हें GDPR व्यक्तिगत डेटा के रूप में मानता है। रोलआउट से पहले प्रत्येक क्लाइंट के साथ प्रतिधारण, पहुंच और उद्देश्य पर सहमति व्यक्त करें, और उन शर्तों को अपने डेटा प्रोसेसिंग समझौते में रिकॉर्ड करें। MSP के रूप में, आप अक्सर अपने क्लाइंट्स के लिए एक प्रोसेसर के रूप में कार्य करेंगे, इसलिए दस्तावेज़ तैयार करें कि प्रत्येक संपत्ति के लॉग को कौन नियंत्रित करता है।

मल्टी-साइट एस्टेट के लिए Shield की कीमत कैसे तय की जाती है?

Shield, SecurePass और Verify के साथ Purple प्लेटफॉर्म का एक सुरक्षा ऐड-ऑन है, इसलिए आप इसे पहले से ही Purple पर चल रही साइटों में जोड़ते हैं। प्रति-साइट कोई हार्डवेयर नहीं है, इसलिए मॉडल करने के लिए कोई उपकरण, शिपिंग या प्रतिस्थापन लागत नहीं है। अपने क्लाइंट्स और साइटों की संख्या के आधार पर मूल्य निर्धारण के लिए Purple से पूछें, और इसमें उन सभी साइटों को शामिल करें जिन्हें आप इस वर्ष ऑनबोर्ड करने की योजना बना रहे हैं।