UK मधील सार्वजनिक WiFi नेटवर्कसाठी IWF अनुपालन

होस्ट: नमस्कार आणि Purple Enterprise IT Briefing मध्ये आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण अशा विषयावर चर्चा करत आहोत जो UK मधील प्रत्येक IT Director, CTO, आणि Network Architect ला माहित असणे अत्यंत आवश्यक आहे: Public WiFi नेटवर्क्ससाठी IWF Compliance. जर तुम्ही रिटेल चेन्स, हॉस्पिटॅलिटी व्हेन्यूज, स्टेडियम्स किंवा पब्लिक सेक्टर बिल्डिंग्ससाठी इन्फ्रास्ट्रक्चर व्यवस्थापित करत असाल, तर गेस्ट WiFi प्रदान करणे केवळ बँडविड्थ आणि कव्हरेजपुरते मर्यादित राहिलेले नाही. हे आता जोखीम कमी करण्याबद्दल (risk mitigation) आहे. मजबूत, प्रमाणित फिल्टरिंगशिवाय इंटरनेटला खुला मार्ग देणे तुमच्या संस्थेला गंभीर कायदेशीर आणि प्रतिष्ठेच्या नुकसानीस कारणीभूत ठरू शकते. आज, आपण थेट मुद्द्यावर बोलणार आहोत. कोणताही शैक्षणिक सिद्धांत नाही - केवळ एक सुसंगत, उच्च-कार्यक्षमता असलेले नेटवर्क कसे तयार करावे याबद्दलची प्रत्यक्ष अंमलबजावणीयोग्य आणि व्हेंडर-तटस्थ मार्गदर्शन. चला थेट मुख्य विषयाकडे वळूया. Internet Watch Foundation, म्हणजेच IWF, UK ची चाइल्ड सेक्स्युअल अ‍ॅब्युज मटेरियल (CSAM) असलेल्या URLs ची निश्चित यादी व्यवस्थापित करते. सार्वजनिक WiFi ऑफर करणाऱ्या कोणत्याही व्हेन्यूसाठी, ही ब्लॉकलिस्ट एकत्रित करणे ही जबाबदार कामकाजाची मूळ पायरी आहे. पण येथे सर्वात महत्त्वाचा मुद्दा आहे: तुम्ही महिन्यातून एकदा स्टॅटिक यादी डाउनलोड करून ती तुमच्या फायरवॉलवर अपलोड करू शकत नाही. IWF ची यादी अत्यंत डायनॅमिक आहे. URLs सतत जोडल्या आणि काढल्या जातात. तुमच्या वेब फिल्टरिंग इंजिनने हा फीड रिअल-टाइम किंवा रिअल-टाइमच्या जवळ असणाऱ्या वेळेत वापरला पाहिजे. जर तुम्ही अशा व्हेंडरचा वापर करत असाल जो अधिकृत IWF सदस्य नाही आणि त्यांचा डायनॅमिक फीड सक्रियपणे वापरत नाही, तर तुम्ही नियमांचे पालन करत नाही आहात. पूर्णविराम. तर, नेटवर्कच्या टोकावर (network edge) आपण प्रत्यक्षात याची रचना कशी करतो? चला तांत्रिक सखोलतेमध्ये जाऊया. IWF चे पालन करण्यासाठी बहु-स्तरीय दृष्टिकोनाची आवश्यकता असते. तुम्ही एकाच नियंत्रण बिंदूवर (choke point) अवलंबून राहू शकत नाही. पहिली पायरी म्हणजे DNS फिल्टरिंग. हा तुमचा संरक्षणाचा पहिला मार्ग आहे. जेव्हा एखादे गेस्ट डिव्हाइस ज्ञात CSAM डोमेनची विनंती करते, तेव्हा तुमचे सुरक्षित DNS त्यात हस्तक्षेप करते आणि त्याला ब्लॉक पेजवर वळवते. हे अत्यंत कार्यक्षम आहे आणि यामुळे नेटवर्कमध्ये अजिबात विलंब (latency) होत नाही. तथापि, आधुनिक नियमांचे पालन करण्यासाठी केवळ DNS फिल्टरिंगमध्ये मूळ त्रुटी आहेत. का? कारण DNS डोमेन पातळीवर काम करते. IWF ची यादी अनेकदा अचूक URLs - म्हणजेच एखाद्या साइटच्या आतील विशिष्ट पेजेस दर्शवते. जर तुम्ही फक्त DNS वापरत असाल, तर तुम्हाला दोन मोठ्या समस्यांना तोंड द्यावे लागेल. एकतर तुमचे फिल्टरिंग अपुरे पडेल ज्यामुळे थेट IP द्वारे प्रवेश मिळेल, किंवा तुम्ही प्रमाणाबाहेर ब्लॉक कराल, ज्यामुळे फक्त एका आक्षेपार्ह URL मुळे संपूर्ण कायदेशीर डोमेन ब्लॉक होईल. अति-ब्लॉकिंगमुळे युजर्स निराश होतात आणि सपोर्ट तिकीट वाढतात. हे आपल्याला दुसऱ्या पायरीकडे घेऊन जाते: HTTP आणि HTTPS Deep Packet Inspection, विशेषतः SNI inspection. कारण बहुतांश वेब ट्रॅफिक HTTPS द्वारे एन्क्रिप्ट केलेले असते, ट्रॅफिक डिक्रिप्ट केल्याशिवाय तुम्ही संपूर्ण URL पाथ सहज पाहू शकत नाही. आता, काही नेटवर्क इंजीनियर्स संपूर्ण SSL डिक्रिप्शन - म्हणजेच SSL Inspection चा सल्ला देऊ शकतात. मला स्पष्ट करू द्या: सार्वजनिक गेस्ट नेटवर्कवर असे कधीही करू नका. यासाठी गेस्ट डिव्हाइसेसवर सानुकूल रूट प्रमाणपत्रे (root certificates) स्थापित करावी लागतात, जे लागू करणे अशक्य आहे, ब्राउझरचा विश्वास तोडते आणि गोपनीयतेचे मोठे उल्लंघन आहे. उद्योग मानक हे SNI - Server Name Indication - तपासणी आहे. SNI तुमच्या फायरवॉलला सुरुवातीच्या TLS हँडशेककडे पाहण्याची आणि एन्क्रिप्टेड टनेल स्थापित होण्यापूर्वी क्लायंट कोणत्या होस्टनावची विनंती करत आहे हे पाहण्याची अनुमती देते. प्रगत SNI तपासणी आणि डायनॅमिक IP वर्गीकरणासह मजबूत DNS फिल्टरिंग एकत्र करून, तुम्ही एंड-टू-एंड एन्क्रिप्शन न तोडता अचूकपणे IWF सूची लागू करू शकता. चला अंमलबजावणीच्या शिफारसी आणि तुम्ही टाळल्या पाहिजेत अशा त्रुटींबद्दल बोलूया. पहिले, बायपासची समस्या. युजर्स त्यांच्या DNS सेटिंग्ज 8.8.8.8 वर बदलून तुमच्या नियंत्रणांना बायपास करू शकत असतील, तर तुमचे फिल्टरिंग निरुपयोगी आहे. तुम्ही तुमचे एज राउटर किंवा फायरवॉल UDP आणि TCP पोर्ट 53, तसेच DNS over TLS साठी पोर्ट 853 वरील आउटबाउंड ट्रॅफिक ब्लॉक करण्यासाठी कॉन्फिगर केले पाहिजेत. सर्व DNS विनंत्या तुमच्या सुसंगत इन्फ्रास्ट्रक्चरद्वारे पाठवण्यास भाग पाडा. याव्यतिरिक्त, DNS over HTTPS किंवा DoH वर बारीक लक्ष ठेवा. आधुनिक ब्राउझर वाढत्या प्रमाणात DoH चा वापर करत आहेत, जे मानक HTTPS ट्रॅफिकमध्ये DNS क्वेरी समाविष्ट करते. ब्राउझरला तुमच्या स्थानिक, सुरक्षित DNS वर परत येण्यास भाग पाडण्यासाठी तुमची फायरवॉल ज्ञात DoH रिझोल्व्हर एंडपॉइंट्स ब्लॉक करण्यासाठी कॉन्फिगर केली आहे याची तुम्ही खात्री करणे आवश्यक आहे. दुसरे, Captive Portal. Captive Portal ही केवळ तुमचा लोगो लावण्याची जागा नाही; ते एक कायदेशीर नियंत्रण गेट आहे. तुमचे Acceptable Use Policy म्हणजेच AUP मध्ये स्पष्टपणे नमूद केले पाहिजे की कंटेंट फिल्टरिंग सक्रिय आहे आणि बेकायदेशीर सामग्रीचा प्रवेश मॉनिटर आणि ब्लॉक केला जातो. प्रवेश मिळवण्यापूर्वी युजर्सनी हे AUP सक्रियपणे स्वीकारले पाहिजे. हे तुम्हाला कायदेशीर संरक्षण प्रदान करते. तिसरे, लॉगिंग. ब्लॉक केलेल्या प्रवेशाच्या प्रयत्नांचे लॉग, डिव्हाइस MAC ॲड्रेस आणि सेशन डेटाशी संबंधित असलेले लॉग किमान 12 महिन्यांसाठी राखून ठेवण्यासाठी तुम्हाला तुमची सिस्टम कॉन्फिगर करावी लागेल. हे GDPR शी सुसंगत आहे आणि एखादी घटना घडल्यास कायद्याची अंमलबजावणी करणाऱ्या संस्थांच्या तपासाला मदत करते. आणि शेवटी, नेटवर्कचे वर्गीकरण (नेटवर्क सेगमेंटेशन). गेस्ट ट्रॅफिक कधीही ऑपरेशनल ट्रॅफिकमध्ये मिक्स करू नका. तुमचे Guest VLAN तुमच्या पॉइंट ऑफ सेल (POS) सिस्टम किंवा कॉर्पोरेट इन्फ्रास्ट्रक्चरपासून पूर्णपणे वेगळे असले पाहिजे. गेस्ट नेटवर्कवर कडक वेब फिल्टरिंग लागू करा, परंतु व्यवहारांसाठी शून्य विलंब (झिरो लेटन्सी) निश्चित करण्यासाठी तुमच्या POS नेटवर्कसाठी कडक अलाउ-लिस्ट्स वापरा. चला, क्षेत्रात आम्हाला वारंवार भेडसावणाऱ्या सामान्य परिस्थितींवर आधारित जलद प्रश्नोत्तरांची वेळ झाली आहे. प्रश्न 1: "आमच्या नवीन फायरवॉल कॉन्फिगरेशनची चाचणी घेण्यासाठी आम्ही वास्तविक IWF URL वापरू शकतो का?" उत्तर: अजिबात नाही. त्या URL वर प्रवेश करणे बेकायदेशीर आहे. तुमचे फिल्टरिंग इंजिन योग्यरित्या कार्य करत आहे हे प्रमाणित करण्यासाठी IWF केवळ विशिष्ट, सुरक्षित चाचणी URL प्रदान करते. त्या वापरा. प्रश्न 2: "आमच्या मार्केटिंग टीमला विना Captive Portal असलेले 'अडथळा नसलेले' खुले WiFi नेटवर्क हवे आहे. हे सुसंगत आहे का?" उत्तर: नाही. Captive Portal शिवाय, तुम्ही Acceptable Use Policy लागू करू शकत नाही, याचा अर्थ तुमचा युजरसोबत कोणताही कायदेशीर करार नाही. हे ठिकाणाला मोठ्या कायदेशीर दायित्वास सामोरे जाण्यास प्रवृत्त करते. प्रश्न 3: "VPN वापरणाऱ्या पाहुण्यांच्या बाबतीत आम्ही काय करावे?" उत्तर: हॉटेलसारख्या वातावरणात, व्यावसायिक प्रवाशांना VPN ची आवश्यकता असते. तुम्ही त्या सर्वांना ब्लॉक करू शकत नाही. तथापि, तुम्ही मानक पोर्ट्सना बायपास करणाऱ्या अत्यधिक, सततच्या एन्क्रिप्टेड टनेल्सवर लक्ष ठेवले पाहिजे, जे कायदेशीर कॉर्पोरेट प्रवेशाऐवजी गैरवापराचे संकेत देऊ शकतात. चला पुढील चरणांचा सारांश पाहूया. अनुपालन (Compliance) हा खर्चाचा केंद्र नाही; हे ब्रँडचे संरक्षण आहे. तुमच्या ठिकाणाचे नाव बेकायदेशीर सामग्रीशी जोडले जाण्यामुळे होणारे प्रतिष्ठेचे नुकसान हे उपयोजन खर्चापेक्षा खूप जास्त आहे. हे योग्यरित्या करण्यासाठी: 1. तुमचा वेब फिल्टरिंग विक्रेता सक्रिय IWF सदस्य असल्याची पडताळणी करा. 2. सुरक्षित DNS आणि SNI तपासणी दोन्ही वापरून दुहेरी-स्तर फिल्टरिंग लागू करा. 3. बायपास रोखण्यासाठी आउटबाउंड DNS पोर्ट्स लॉक करा. 4. Captive Portal द्वारे AUP लागू करा. 5. तुमचे लॉग 12 महिन्यांसाठी राखून ठेवा. तुम्ही या चरणांचे पालन केल्यास, तुम्ही असे नेटवर्क तयार कराल जे केवळ उच्च-कार्यक्षमता देणारे नसेल तर मूलभूतपणे सुरक्षित आणि अनुपालन करणारे असेल. या Purple Enterprise IT Briefing मध्ये सामील झाल्याबद्दल धन्यवाद. अधिक तपशीलवार आर्किटेक्चर आकृत्या आणि अंमलबजावणी चेकलिस्टसाठी, संपूर्ण तांत्रिक मार्गदर्शकाचा संदर्भ घ्या. सुरक्षित रहा, आणि आपण पुढील वेळी भेटू.