गेस्ट WiFi RFP आवश्यकताएं: ऑनबोर्डिंग, सुरक्षा और एनालिटिक्स में क्या निर्दिष्ट करें

एक गेस्ट WiFi RFP को पांच क्षेत्रों में मापने योग्य आवश्यकताओं को निर्धारित करना चाहिए। ऑनबोर्डिंग: कैप्टिव पोर्टल, सहमति कैप्चर और WCAG 2.2 एक्सेसिबिलिटी। सुरक्षा: IEEE 802.1X, RADIUS, Passpoint और WPA3। हार्डवेयर: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist और Ubiquiti UniFi के लिए नाम निर्दिष्ट सहायता। अनुपालन: GDPR, PCI DSS v4.0 और सुरक्षात्मक DNS। एनालिटिक्स: निर्यात योग्य फ़र्स्ट-पार्टी डेटा। प्रमाण के आधार पर बोलीदाताओं को अंक दें।

गेस्ट WiFi RFP में वास्तव में क्या निर्दिष्ट करने की आवश्यकता है?

एक गेस्ट WiFi RFP एक ढीले संक्षिप्त विवरण को, जैसे "मेहमानों के लिए मुफ्त WiFi", ऐसी आवश्यकताओं में बदल देता है जिन्हें कोई बोलीदाता पास या फेल कर सकता है। यह परिभाषित करता है कि लोग कैसे जुड़ते हैं, ट्रैफ़िक को कैसे सुरक्षित किया जाता है और प्लेटफ़ॉर्म को किस हार्डवेयर पर चलना चाहिए। यह यह भी तय करता है कि व्यक्तिगत डेटा को कैसे संभाला जाता है और आपको क्या रिपोर्टिंग वापस मिलती है।

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

बहु-स्थल संपत्तियों के लिए, RFP अनुबंध की अवधि के लिए आपका ऑपरेटिंग मॉडल भी निर्धारित करता है। कैप्टिव पोर्टल वह वेब पृष्ठ है जो एक डिवाइस इंटरनेट एक्सेस प्राप्त करने से पहले देखता है। आप हर साइट पर एक कैप्टिव पोर्टल और एक सहमति रिकॉर्ड चला सकते हैं। इसका विकल्प प्रत्येक हार्डवेयर विक्रेता के लिए एक अलग सेटअप है। बाद में खंडित संपत्ति को सुलझाने में अभी एक एकल मानक निर्दिष्ट करने की तुलना में बहुत अधिक लागत आती है।

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

गेस्ट WiFi RFP लिखने से पहले आपको किन चीज़ों की आवश्यकता है?

पहले ड्राफ्ट से पहले पांच इनपुट एकत्र करें। इनमें से प्रत्येक अनुबंध दिए जाने के बाद परिवर्तन अनुरोधों के एक सामान्य स्रोत को रोकता है।

• प्रति स्थल हार्डवेयर इन्वेंट्री। प्रत्येक साइट पर एक्सेस पॉइंट (AP) विक्रेता, मॉडल, प्रबंधन प्लेटफ़ॉर्म और फर्मवेयर का रिकॉर्ड रखें। ध्यान दें कि क्या प्रत्येक साइट क्लाउड डैशबोर्ड का उपयोग करती है या ऑन-प्रीमिसिस कंट्रोलर का। हमारी गाइड WLC (वायरलेस LAN कंट्रोलर) क्या है और क्या आपको अभी भी इसकी आवश्यकता है? अंतर समझाती है।
• प्रकार के अनुसार स्थलों की सूची। वर्टिकल और आकार के अनुसार साइटों का समूह बनाएं, क्योंकि स्टेडियम के कॉनकोर्स और होटल लॉबी को अलग-अलग ऑनबोर्डिंग की आवश्यकता होती है। उन लोगों के नाम दर्ज करें जिनकी प्रत्येक स्थल सेवा करता है: मेहमान, खरीदार, यात्री, प्रशंसक, मरीज या आगंतुक।
• डेटा मैप। तय करें कि डेटा कंट्रोलर के रूप में कौन कार्य करता है, कौन से सिस्टम WiFi डेटा प्राप्त करेंगे और आप इसे कब तक रखेंगे। आपके डेटा सुरक्षा अधिकारी को RFP बाहर जाने से पहले इस पर हस्ताक्षर करने चाहिए।
• आपकी भुगतान सीमाएं। कार्ड भुगतान स्वीकार करने वाली प्रत्येक साइट की सूची बनाएं। नोट करें कि क्या भुगतान उपकरण अतिथि ट्रैफ़िक के साथ स्विच या सर्किट साझा करते हैं। यह आपके PCI DSS दायरा (scope) को परिभाषित करता है।
• सफलता के मापदंड। उन संख्याओं पर सहमति व्यक्त करें जिनकी आप रिपोर्ट करेंगे, जैसे कि लॉगिन, ऑप्ट-इन दर, बार-बार आने वाले विज़िटर और सहायता टिकट। इसके बाद बोलीदाता यह दिखा सकते हैं कि उनकी रिपोर्टिंग इनमें से प्रत्येक को कैसे तैयार करती है।

शुरुआत से ही IT, सुरक्षा, डेटा सुरक्षा, मार्केटिंग और वेन्यू ऑपरेशन्स को शामिल करें। गेस्ट WiFi इन पाँचों टीमों को छूता है। एक टीम द्वारा लिखी गई आवश्यकता अक्सर दूसरी टीम को बाधित करती है।

आप गेस्ट WiFi RFP आवश्यकताओं को अनुभाग दर अनुभाग कैसे लिखते हैं?

RFC 2119 में दिए गए सम्मेलन का पालन करते हुए, प्रत्येक आवश्यकता को "होना चाहिए (must)" या "होना चाहिए (should)" के साथ लिखें। "होना चाहिए (must)" एक पास या फ़ेल का पैमाना है। "होना चाहिए (should)" को अंक दिए जाते हैं। बोलीदाताओं से प्रमाण के साथ प्रत्येक पंक्ति का उत्तर देने के लिए कहें: एक दस्तावेज़, एक प्रमाणपत्र, एक संदर्भ साइट या एक लाइव प्रदर्शन।

ऑनबोर्डिंग और कैप्टिव पोर्टल आवश्यकताएं

ऑनबोर्डिंग वह जगह है जहाँ अतिथि आपके नेटवर्क का आकलन करते हैं, और जहाँ आपके सहमति रिकॉर्ड बनाए जाते हैं। यह कैप्टिव पोर्टल RFP चेकलिस्ट आवश्यक बातों को कवर करती है।

• लॉगिन तरीके। प्लेटफॉर्म को ईमेल, सोशल लॉगिन, SMS और एक्सेस कोड का समर्थन करना चाहिए, जो प्रति वेन्यू कॉन्फ़िगर करने योग्य हो।
• सचेत-विकल्प वाले ऑप्ट-इन (Conscious-choice opt-ins)। मार्केटिंग सहमति एक अलग, अनटिक किया गया विकल्प होना चाहिए, जिसे कभी भी नियमों और शर्तों की स्वीकृति के साथ बंडल न किया जाए। GDPR आर्टिकल 7 के अनुसार सहमति का प्रदर्शन किया जा सकना चाहिए और इसे वापस लेना उतना ही आसान होना चाहिए जितना कि देना।
• अक्सेसिबिलिटी (Accessibility)। कैप्टिव पोर्टल को WCAG 2.2 लेवल AA को पूरा करना चाहिए।
• विश्वसनीय पोर्टल पहचान (Reliable portal detection)। प्लेटफॉर्म को कैप्टिव पोर्टल API (RFC 8908) और DHCP कैप्टिव पोर्टल विकल्प (RFC 8910) का समर्थन करना चाहिए। दोनों आधुनिक उपकरणों को रीडायरेक्ट लूप के बिना लॉगिन पेज ढूंढने में मदद करते हैं।
• बार-बार आने वाले विज़िटर की पहचान। iOS 14 और Android 10 से आगे के संस्करण डिफ़ॉल्ट रूप से रैंडमाइज़्ड MAC पते का उपयोग करते हैं। बोलीदाताओं से पूछें कि वे उपकरण के हार्डवेयर पते पर निर्भर हुए बिना बार-बार आने वाले अतिथि की पहचान कैसे करते हैं।
• केंद्रीय नियंत्रण (Central control)। हेड ऑफिस को प्रत्येक वेन्यू के लिए स्थानीय ओवरराइड के साथ ब्रांडिंग, शर्तों और सहमति के शब्दों को केंद्रीय रूप से प्रबंधित करना चाहिए।

Purple गेस्ट WiFi कैप्टिव पोर्टल में सचेत-विकल्प वाले ऑप्ट-इन का निर्माण करता है और इसे पूरी संपत्ति में केंद्रीय रूप से प्रबंधित करता है।

प्रमाणीकरण, RADIUS और Passpoint आवश्यकताएं

RADIUS वह प्रोटोकॉल है जिसका उपयोग एक AP किसी केंद्रीय सर्वर से यह पूछने के लिए करता है कि किसी उपकरण को प्रवेश दिया जाए या नहीं। इसे RFC 2865 में परिभाषित किया गया है। RFC 2866 में परिभाषित RADIUS एकाउंटिंग, सत्र के शुरू होने, रुकने और डेटा के उपयोग को रिकॉर्ड करता है। बहु-वेन्यू संपत्ति के लिए, निम्नलिखित निर्दिष्ट करें।

• रिडंडेंसी के साथ क्लाउड RADIUS। यदि एक डेटा सेंटर विफल हो जाता है तो भी प्रमाणीकरण काम करता रहना चाहिए। आर्किटेक्चर और 12 महीने की मापी गई उपलब्धता का विवरण मांगें।
• एनक्रिप्टेड RADIUS ट्रांसपोर्ट। जहां RADIUS सार्वजनिक इंटरनेट को पार करता है, वहां RadSec (TLS के ऊपर RADIUS, RFC 6614) या एक एनक्रिप्टेड टनल की आवश्यकता रखें।
• डायनेमिक ऑथराइजेशन (Dynamic authorisation)। प्लेटफॉर्म को पुनः कनेक्ट करने के लिए बाध्य किए बिना सत्र को समाप्त करने या बदलने के लिए CoA संदेश (RFC 5176) भेजने चाहिए।
• विभाजन (Segmentation)। गेस्ट ट्रैफ़िक को उसके स्वयं के VLAN पर होना चाहिए, जो कर्मचारियों और भुगतान प्रणालियों से अलग एक लॉजिकल नेटवर्क सेगमेंट हो। क्लाइंट आइसोलेशन द्वारा गेस्ट डिवाइसों को एक-दूसरे तक पहुँचने से रोका जाना चाहिए।
• ओपन नेटवर्क पर एन्क्रिप्शन। Enhanced Open (Opportunistic Wireless Encryption, RFC 8110) सहित WPA3 की आवश्यकता होती है। यह बिना किसी साझा पासवर्ड के प्रत्येक कनेक्शन को एन्क्रिप्ट करता है।
• जहाँ आवश्यक हो वहाँ व्यक्तिगत कुंजियाँ (Individual keys)। iPSK (identity pre-shared key) किसी साझा नेटवर्क पर प्रत्येक व्यक्ति या डिवाइस को उसका स्वयं का WiFi पासवर्ड प्रदान करता है। यह लंबी अवधि के लिए ठहरने वाले मेहमानों, प्रदर्शकों और इवेंट क्रू के लिए उपयुक्त है। Purple इसे SecurePass के माध्यम से प्रदान करता है।

Passpoint, जिसे Hotspot 2.0 भी कहा जाता है, IEEE 802.11u पर आधारित है। यह किसी डिवाइस को बिना किसी कैप्टिव पोर्टल के स्वचालित रूप से नेटवर्क खोजने और उससे जुड़ने की अनुमति देता है। प्रमाणीकरण IEEE 802.1X पर चलता है, जो पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल के लिए मानक है, इसलिए क्रेडेंशियल्स एन्क्रिप्टेड रहते हैं। Wireless Broadband Alliance द्वारा संचालित OpenRoaming, Passpoint पर निर्मित एक फेडरेशन है। यह लोगों को उनके पास पहले से मौजूद पहचान के साथ भाग लेने वाले नेटवर्क में शामिल होने की अनुमति देता है।

चरण एक में Passpoint और OpenRoaming को "होना चाहिए" (should) आवश्यकताओं के रूप में निर्दिष्ट करें, साथ ही एक लागत-आधारित रोडमैप भी शामिल करें। Purple OpenRoaming का समर्थन करता है, ताकि बार-बार आने वाले मेहमान आपके स्थानों पर स्वचालित रूप से कनेक्ट हो सकें।

यदि RFP में Staff WiFi भी शामिल है, तो Microsoft Entra ID, Okta और Google Workspace के साथ एकीकरण आवश्यक है। यह बिना किसी मैनुअल पासवर्ड परिवर्तन के नए जुड़ने वाले, स्थानांतरित होने वाले और छोड़ने वाले कर्मचारियों को नेटवर्क एक्सेस के साथ तालमेल में रखता है।

हार्डवेयर-न्यूट्रल AP संगतता

"प्रमुख एंटरप्राइज हार्डवेयर के साथ संगत" का मूल्यांकन नहीं किया जा सकता है। ऐसे प्रत्येक प्लेटफॉर्म का नाम दें जिसे आप चलाते हैं, या अनुबंध के दौरान अपना सकते हैं। फिर प्रत्येक पर समान पाँच क्षमताओं की आवश्यकता रखें।

1. बाहरी कैप्टिव पोर्टल सहायता।
2. RADIUS प्रमाणीकरण और लेखांकन (accounting)।
3. वॉल्ड गार्डन: डोमेन की प्री-लॉगिन अनुमति सूची जिसकी पोर्टल और सोशल लॉगिन को आवश्यकता होती है।
4. CoA सहायता, या सत्रों को समाप्त करने के लिए एक प्रलेखित विकल्प।
5. उस प्लेटफॉर्म पर एक प्रकाशित एकीकरण मार्गदर्शिका और कम से कम एक लाइव संदर्भ।

विक्रेता	RFP में नाम दिया जाने वाला प्रबंधन प्लेटफॉर्म	अनुरोध करने के लिए न्यूनतम साक्ष्य
Cisco Meraki	Meraki डैशबोर्ड	एकीकरण मार्गदर्शिका, लाइव संदर्भ, आपके फर्मवेयर पर पायलट
HPE Aruba	HPE Aruba नेटवर्किंग सेंट्रल या मोबिलिटी कंट्रोलर	एकीकरण मार्गदर्शिका, लाइव संदर्भ, आपके फर्मवेयर पर पायलट
Ruckus	RUCKUS SmartZone या RUCKUS One	एकीकरण मार्गदर्शिका, लाइव संदर्भ, आपके फर्मवेयर पर पायलट
Juniper Mist	Juniper Mist क्लाउड	एकीकरण मार्गदर्शिका, लाइव संदर्भ, आपके फर्मवेयर पर पायलट
Ubiquiti UniFi	UniFi नेटवर्क एप्लिकेशन	एकीकरण मार्गदर्शिका, लाइव संदर्भ, आपके फर्मवेयर पर पायलट
Cambium	cnMaestro	एकीकरण मार्गदर्शिका, लाइव संदर्भ, आपके फर्मवेयर पर पायलट
Extreme	ExtremeCloud IQ	एकीकरण मार्गदर्शिका, लाइव संदर्भ, आपके फर्मवेयर पर पायलट
Fortinet	FortiGate एकीकृत वायरलेस कंट्रोलर	एकीकरण मार्गदर्शिका, लाइव संदर्भ, आपके फर्मवेयर पर पायलट

प्रत्येक बोलीदाता से कहें कि वे उन फ़र्मवेयर श्रेणियों का उल्लेख करें जिनका वे समर्थन करते हैं, फिर अपने फ़र्मवेयर के विरुद्ध उसका परीक्षण करें। Purple हार्डवेयर-अज्ञेयवादी है और सभी आठ प्लेटफ़ॉर्म पर क्लाउड ओवरले के रूप में चलता है। इसमें पुराने सिस्टम को हटाकर नए लगाने की आवश्यकता नहीं है। आपको अपने अगले WiFi अपग्रेड के लिए नए हार्डवेयर की आवश्यकता क्यों नहीं है व्यावसायिक पक्ष को कवर करता है। Ruckus संपत्तियों के लिए, Ruckus SmartZone और RUCKUS One गेस्ट WiFi बनाम बाहरी कैप्टिव पोर्टल प्लेटफ़ॉर्म देखें।

आवश्यकता के अनुसार GDPR क्लॉज़

गेस्ट WiFi बड़े पैमाने पर व्यक्तिगत डेटा एकत्र करता है, इसलिए अनुबंध में ये क्लॉज़ होने चाहिए।

• एक डेटा प्रोसेसिंग समझौता जो GDPR अनुच्छेद 28 को पूरा करता है, जिसमें उद्देश्य, सुरक्षा, उप-प्रोसेसर और डेटा हटाना शामिल है।
• सहमति रिकॉर्ड जो प्रत्येक ऑप्ट-इन के लिए टाइमस्टैम्प, वर्डिंग संस्करण और चैनल दिखाते हैं, जिन्हें मांग पर निर्यात किया जा सकता है।
• कॉन्फ़िगर योग्य रिटेंशन स्वचालित रूप से हटाने की सुविधा के साथ, जो अनुच्छेद 5(1)(e) में भंडारण सीमा के सिद्धांत के अनुरूप है।
• डेटा विषय टूल किसी एक व्यक्ति के डेटा को खोजने, निर्यात करने और मिटाने के लिए। आपको अनुच्छेद 12(3) के तहत एक महीने के भीतर अनुरोधों का उत्तर देना होगा।
• Processor की ओर से बिना किसी अनुचित देरी के उल्लंघन की अधिसूचना, जैसा कि अनुच्छेद 33(2) के लिए आवश्यक है। इसके बाद आपके पास अनुच्छेद 33(1) के तहत नियामक को सूचित करने के लिए 72 घंटे का समय होता है।
• अंतर्राष्ट्रीय स्थानांतरण। बोलीदाता को यह बताना होगा कि डेटा कहाँ रखा गया है और UK या EEA के बाहर किसी भी प्रोसेसिंग के लिए स्थानांतरण तंत्र क्या है।
• अनुच्छेद 32 के लिए सुरक्षा प्रमाण, आदर्श रूप से ISO 27001 प्रमाणन।

Purple ISO 27001 प्रमाणित है और GDPR, CCPA तथा Cyber Essentials अनुपालन प्रदान करता है।

आवश्यकता के अनुसार PCI DSS क्लॉज़

गेस्ट WiFi को कभी भी आपके कार्डधारक डेटा वातावरण (CDE) के अंदर नहीं होना चाहिए। CDE उन सिस्टम को कवर करता है जो कार्ड डेटा को स्टोर, प्रोसेस या ट्रांसमिट करते हैं। PCI DSS v4.0 आपको सेग्मेंटेशन के माध्यम से स्कोप को कम करने की अनुमति देता है, लेकिन आपको यह साबित करना होगा कि यह काम करता है।

• बोलीदाता को लिखित रूप में यह पुष्टि करनी होगी कि गेस्ट ट्रैफ़िक कभी भी CDE से होकर नहीं गुजरता है, और इसके डिज़ाइन को दस्तावेज़बद्ध करना होगा।
• डिज़ाइन को आपके सेग्मेंटेशन पैनेट्रेशन टेस्ट का समर्थन करना चाहिए, जो आवश्यकता 11.4.5 के तहत कम से कम हर 12 महीने में आवश्यक है।
• कैप्टिव पोर्टल पर कोई भी कार्ड डेटा दर्ज नहीं किया जा सकता है। किसी भी सशुल्क पहुंच के लिए PCI DSS अनुपालन भुगतान प्रदाता का उपयोग किया जाना चाहिए, जिसका अनुपालन प्रमाण पत्र (Attestation of Compliance) प्रदान किया गया हो।
• आवश्यकता 11.2.1 के तहत अनधिकृत वायरलेस एक्सेस पॉइंट्स के लिए आपका त्रैमासिक परीक्षण अभी भी गेस्ट क्षेत्रों को कवर करता है।

आवश्यकता के अनुसार प्रोटेक्टिव DNS क्लॉज़

प्रोटेक्टिव DNS डिवाइसों को ऐसे डोमेन को रिज़ॉल्व करने से रोकता है जो मालवेयर, फ़िशिंग या कमांड-एंड-कंट्रोल सर्वर की मेज़बानी के लिए जाने जाते हैं। UK नेशनल साइबर सिक्योरिटी सेंटर (NCSC) सार्वजनिक क्षेत्र के निकायों को प्रोटेक्टिव DNS सेवा प्रदान करता है। निम्नलिखित बातें निर्दिष्ट करें।

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

Purple के सुरक्षा ऐड-ऑन SecurePass, Verify और Shield हैं। ऊपर दिए गए क्लॉज़ के विरुद्ध प्रत्येक के प्रदर्शन का अनुरोध करें।

एनालिटिक्स और एकीकरण आवश्यकताएं

एंटरप्राइज गेस्ट WiFi खरीद में अक्सर एनालिटिक्स को कम आंका जाता है, फिर भी यहीं आपको रिटर्न मिलता है। निम्नलिखित को निर्दिष्ट करें:

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

Purple WiFi Analytics प्रति स्थान इन मेट्रिक्स की रिपोर्ट करता है और CRM तथा मार्केटिंग प्लेटफॉर्म के साथ एकीकृत होता है।

सेवा स्तर और प्रमाणपत्र

• उपलब्धता: सेवा क्रेडिट के साथ मासिक अपटाइम SLA की आवश्यकता रखें। Purple का प्लेटफॉर्म 99.999% अपटाइम पर चलता है।
• सपोर्ट: घंटे, गंभीरता के आधार पर प्रतिक्रिया समय और एक नामित एस्केलेशन संपर्क निर्दिष्ट करें।
• प्रमाणपत्र: ISO 27001 की आवश्यकता रखें। यूके केंद्र सरकार के अनुबंध जो व्यक्तिगत डेटा को संभालते हैं, उन्हें प्रोक्योरमेंट पॉलिसी नोट 09/14 के तहत Cyber Essentials की आवश्यकता होती है।
• स्केल संदर्भ: अपने आकार के संदर्भों का अनुरोध करें। Purple 90 से अधिक देशों में 80,000+ लाइव स्थानों को संचालित करता है और इसने 2024 में 440 मिलियन लॉगिन संभाले हैं (Purple का अपना डेटा)।

आवश्यकताएं स्कोरिंग मैट्रिक्स

क्षेत्र	आवश्यकता	प्राथमिकता	अनुरोध करने के लिए साक्ष्य
ऑनबोर्डिंग	अलग, अनटिक किया गया मार्केटिंग ऑप्ट-इन	अनिवार्य	पोर्टल स्क्रीनशॉट और एक नमूना सहमति निर्यात
ऑनबोर्डिंग	WCAG 2.2 AA कैप्टिव पोर्टल	अनिवार्य	स्वतंत्र एक्सेसिबिलिटी ऑडिट रिपोर्ट
प्रमाणीकरण	फेलओवर के साथ क्लाउड RADIUS	अनिवार्य	आर्किटेक्चर आरेख और 12 महीने का उपलब्धता डेटा
प्रमाणीकरण	RadSec या एन्क्रिप्टेड RADIUS टनल	अनिवार्य	डिज़ाइन दस्तावेज़
प्रमाणीकरण	Passpoint और OpenRoaming	होना चाहिए	लाइव संदर्भ साइट
एन्क्रिप्शन	WPA3 और एन्हांस्ड ओपन	होना चाहिए	आपके APs पर पायलट परीक्षण
हार्डवेयर	आपके द्वारा चलाए जाने वाले प्रत्येक प्लेटफॉर्म के लिए नामित समर्थन	अनिवार्य	एकीकरण गाइड और पायलट परिणाम
GDPR	अनुच्छेद 28 DPA और रिटेंशन नियंत्रण	अनिवार्य	हस्ताक्षरित DPA और रिटेंशन सेटिंग्स डेमो
PCI DSS	CDE के बाहर गेस्ट ट्रैफिक	अनिवार्य	विभाजन डिज़ाइन और परीक्षण समर्थन विवरण
सुरक्षात्मक DNS	ब्लॉक पेज के साथ खतरा और श्रेणी फ़िल्टरिंग	सार्वजनिक क्षेत्र के लिए अनिवार्य, अन्यत्र होना चाहिए	लाइव ब्लॉक परीक्षण और नमूना मासिक रिपोर्ट
एनालिटिक्स	एग्जिट पर पूर्ण डेटा एक्सपोर्ट	अनिवार्य	अनुबंध खंड और नमूना एक्सपोर्ट फ़ाइल
सेवा	सेवा क्रेडिट के साथ अपटाइम SLA	अनिवार्य	SLA अनुसूची

आप यह कैसे जांचते हैं कि कोई बोलीदाता डिलीवरी कर सकता है?

दो चरणों में मूल्यांकन करें: कागज़ी, फिर पायलट। कोई भी विफल "अनिवार्य" शर्त कागज़ी चरण में ही बोलीदाता को बाहर कर देती है। अपनी प्राथमिकताओं से मेल खाने के लिए शेष "वैकल्पिक" पंक्तियों का भार तय करें। एक विशिष्ट विभाजन इस प्रकार है: सुरक्षा और अनुपालन 30%, ऑनबोर्डिंग 20%, हार्डवेयर 15%, एनालिटिक्स 15%, सेवा 10% और वाणिज्यिक 10%।

विभिन्न हार्डवेयर प्लेटफ़ॉर्म पर दो या अधिक स्थानों पर 30-दिवसीय पायलट चलाएं। इनमें से प्रत्येक का परीक्षण करें और पास या फेल दर्ज करें।

• कैप्टिव पोर्टल iOS, Android, Windows और macOS पर पहली बार में दिखाई देता है।
• दोबारा आने वाले अतिथि की दूसरी विज़िट पर पहचान की जाती है।
• सहमति एक्सपोर्ट टाइमस्टैम्प और शब्दों का संस्करण दिखाता है।
• मिटाने का अनुरोध उस व्यक्ति को प्लेटफ़ॉर्म और आपके कनेक्टेड CRM से हटा देता है।
• सिमुलेटेड RADIUS फेलओवर के दौरान प्रमाणीकरण जारी रहता है।
• एक CoA संदेश बिना किसी पुनः रीकनेक्ट के सत्र को समाप्त कर देता है।
• एक ज्ञात परीक्षण डोमेन आपके ब्रांडेड पेज के साथ ब्लॉक कर दिया जाता है।
• अतिथि VLAN से भुगतान नेटवर्क पर कनेक्शन का प्रयास विफल रहता है।

थ्रूपुट और कवरेज का परीक्षण प्लेटफ़ॉर्म से अलग करें। इंटरनेट के लिए WiFi: यह कैसे काम करता है और क्या जांचना है बुनियादी बातों को कवर करता है।

व्यावहारिक रूप से यह कैसा दिखता है?

नीचे दिए गए तीन परिदृश्य सामान्य खरीद पैटर्न से बने उदाहरणात्मक समग्र रूप हैं। ये ग्राहक केस स्टडी नहीं हैं।

दो हार्डवेयर प्लेटफ़ॉर्म पर एक 45-होटल समूह

स्थिति। समूह 30 होटलों में Cisco Meraki और अधिग्रहण किए गए 15 स्थानों पर HPE Aruba चलाता था। प्रत्येक संपत्ति का अपना कैप्टिव पोर्टल था। 15 अधिग्रहित स्थानों पर, मार्केटिंग सहमति को शर्तों की स्वीकृति के साथ बंडल किया गया था।

क्या किया गया था। RFP ने दोनों प्लेटफ़ॉर्म को "अनिवार्य" आवश्यकताओं के रूप में नामित किया। इसमें एक पोर्टल, एक सहमति रिकॉर्ड और अलग ऑप्ट-इन की आवश्यकता थी। पायलट ने प्रत्येक प्लेटफ़ॉर्म पर एक होटल को कवर किया।

परिणाम। पांच में से दो बोलीदाता हार्डवेयर गेट में विफल रहे क्योंकि वे केवल एक प्लेटफ़ॉर्म का समर्थन करते थे। जीतने वाले ओवरले ने सभी 15 Aruba स्थानों को उनके मौजूदा APs पर रखा। गो-लाइव से पहले सभी 15 स्थानों पर बंडल की गई सहमति को हटा दिया गया था।

PCI DSS दायरे में एक 120-स्टोर रिटेल चेन

स्थिति। पुराने स्टोरों में भुगतान टर्मिनल अतिथि APs के साथ स्विच साझा करते थे। इसलिए अतिथि WiFi चेन के PCI DSS मूल्यांकन के दायरे में था।

क्या किया गया था। RFP को दस्तावेजीकरण वाले सेगमेंटेशन डिज़ाइन और 11.4.5 पेनिट्रेशन टेस्ट के लिए लिखित समर्थन की आवश्यकता थी। इसने कैप्टिव पोर्टल पर कार्ड प्रविष्टि को भी प्रतिबंधित कर दिया।

परिणाम। सभी 120 स्टोरों में वार्षिक सेगमेंटेशन परीक्षण पास हो गया। अतिथि WiFi PCI DSS के दायरे से बाहर हो गया, जिसने उन प्रणालियों को सीमित कर दिया जिनका मूल्यांकनकर्ता को समीक्षा करना था।

25 पुस्तकालयों और अवकाश केंद्रों के साथ एक परिषद

स्थिति। परिषद को परिवारों के लिए सुरक्षित सार्वजनिक WiFi, Cyber Essentials और एक सुलभ लॉगिन पेज की आवश्यकता थी।

क्या किया गया। प्रोटेक्टिव DNS एक "अनिवार्य" शर्त थी, जिसमें बच्चों के क्षेत्रों के लिए श्रेणी फ़िल्टरिंग और एक एन्क्रिप्टेड DNS नीति शामिल थी। काउंसिल के डेटा प्रतिधारण शेड्यूल के अनुसार DNS लॉग 90 दिनों के लिए रखे गए थे।

परिणाम। सात में से तीन बोलीदाता WCAG 2.2 गेट को पार करने में विफल रहे। पायलट में, एक शॉर्टलिस्ट किए गए बोलीदाता की फ़िल्टरिंग को DNS over HTTPS के माध्यम से बायपास कर दिया गया था, जिससे वह प्रतिस्पर्धा से बाहर हो गया।

गेस्ट WiFi खरीद में क्या गड़बड़ी होती है, और आप इसे कैसे ठीक करते हैं?

हर बोलीदाता "हां" में जवाब देता है

कारण: आवश्यकताएं सुविधाओं का वर्णन करती हैं, मानकों का नहीं। समाधान: प्रत्येक पंक्ति के लिए RFC, IEEE मानक या GDPR लेख का नाम निर्दिष्ट करें, और साक्ष्य मांगें।

कैप्टिव पोर्टल दिखाई देने में विफल रहता है

कारण: एक अधूरा वॉल्ड गार्डन, या कमजोर कैप्टिव पोर्टल डिटेक्शन। समाधान: RFC 8908 और RFC 8910 समर्थन की आवश्यकता रखें, और पायलट में चार ऑपरेटिंग सिस्टम का परीक्षण करें।

आगंतुकों की संख्या वास्तविक से अधिक दिखाई देती है

कारण: रैंडमाइज्ड MAC एड्रेस एक ही डिवाइस को कई डिवाइसों के रूप में दिखाते हैं। समाधान: लॉगिन पहचान के आधार पर मान्यता की आवश्यकता रखें, और बोलीदाताओं से यह बताने के लिए कहें कि वे दोहराए जाने वाले आगंतुकों की गणना कैसे करते हैं।

सहमति टिक नहीं पाती है

कारण: शर्तों के साथ बंडल किए गए ऑप्ट-इन, या दिखाए गए शब्दों का कोई रिकॉर्ड न होना। समाधान: अलग, बिना टिक किए गए ऑप्ट-इन और वर्जन्ड सहमति रिकॉर्ड की आवश्यकता रखें।

आप बाहर नहीं निकल सकते

कारण: कोई डेटा निर्यात क्लॉज न होना। समाधान: बाहर निकलते समय बिना किसी शुल्क के CSV या JSON में पूर्ण निर्यात की आवश्यकता रखें।

अनुबंध नए हार्डवेयर के लिए बाध्य करता है

कारण: एक विक्रेता जो केवल एक AP ब्रांड से जुड़ा हुआ है। समाधान: आपके द्वारा संचालित प्रत्येक प्लेटफॉर्म का नाम निर्दिष्ट करने वाला एक हार्डवेयर-न्यूट्रल क्लॉज।

इसमें कितनी लागत आती है, और बदले में आपको क्या मिलता है?

छह लागत श्रेणियों के लिए बजट बनाएं: सॉफ्टवेयर लाइसेंस, कोई भी हार्डवेयर, इंस्टॉलेशन, इंटरनेट सर्किट, सहायता और आपकी अपनी टीम का समय। आपके द्वारा चुना गया आर्किटेक्चर अधिकांश अंतर को निर्धारित करता है।

दृष्टिकोण	हार्डवेयर लागत	मल्टी-वेंडर एस्टेट	सहमति और डेटा	प्रत्येक स्थान पर परिवर्तन
मौजूदा APs पर क्लाउड ओवरले (Purple)	शून्य: मौजूदा APs पर चलता है	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet पर एक ही पोर्टल	केंद्रीय सहमति रिकॉर्ड और आपके स्वामित्व वाला फ़र्स्ट-पार्टी डेटा	मौजूदा APs पर SSID और RADIUS कॉन्फ़िगरेशन
AP विक्रेता का बिल्ट-इन कैप्टिव पोर्टल	वर्तमान प्लेटफॉर्म पर शून्य	प्रत्येक हार्डवेयर प्लेटफॉर्म के लिए एक अलग पोर्टल	सहमति और आगंतुक डेटा प्रत्येक प्लेटफॉर्म पर अलग से रखा जाता है	प्रत्येक प्लेटफॉर्म पर कॉन्फ़िगरेशन दोहराया जाता है
रिप-एंड-रिप्लेस प्रबंधित नेटवर्क	हर स्थान पर नए APs और लाइसेंस	पूरे एस्टेट में एक ही हार्डवेयर विक्रेता लागू	प्रदाता की अनुबंध शर्तों द्वारा निर्धारित	हर साइट पर नया AP इंस्टॉलेशन

बोलीदाताओं से एक ही आधार पर मूल्य निर्धारण करने के लिए कहें: पूरी अवधि के लिए प्रति स्थान एक निश्चित वार्षिक मूल्य। ऑनबोर्डिंग, सहायता, अपडेट और एग्जिट लागतों को अलग-अलग मदवार सूचीबद्ध करने की आवश्यकता रखें। सुरक्षा एड-ऑन के रूप में SecurePass, Verify और Shield के साथ Purple तीन योजनाओं: Connect, Capture और Engage के अंतर्गत उद्धरण प्रदान करता है।

रिटर्न चार जगहों से आता है। आपको कानूनी सहमति द्वारा समर्थित फ़र्स्ट-पार्टी डेटा प्राप्त होता है। आप स्टाफिंग की योजना बनाने के लिए पीक ऑवर्स और ड्वेल टाइम देखते हैं। आप ओवरले के माध्यम से हार्डवेयर खर्च से बचते हैं। आपको कई के बजाय सपोर्ट करने के लिए एक ही प्लेटफॉर्म मिलता है। Purple 2012 से 80,000+ लाइव स्थानों पर यह सुविधा प्रदान कर रहा है।

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

क्या गेस्ट WiFi प्लेटफॉर्म हमारे पास पहले से मौजूद एक्सेस पॉइंट्स पर चल सकता है?

हाँ। Purple हार्डवेयर-अग्नोस्टिक है और Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet पर क्लाउड ओवरले के रूप में चलता है। आपके APs रेडियो और ट्रैफ़िक को संभालना जारी रखते हैं। Purple कैप्टिव पोर्टल, क्लाउड RADIUS, सहमति रिकॉर्ड और एनालिटिक्स प्रदान करता है। अपने RFP में, आपके द्वारा चलाए जाने वाले प्रत्येक प्लेटफ़ॉर्म का नाम दें और अनुबंध से पहले अपने स्वयं के फ़र्मवेयर पर एक पायलट की आवश्यकता रखें।

हमें RFP में विक्रेताओं से गेस्ट WiFi की कीमत तय करने के लिए कैसे कहना चाहिए?

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

क्या हमारा गेस्ट WiFi नेटवर्क PCI DSS के दायरे में है?

यह नहीं होना चाहिए, बशर्ते इसे आपके कार्डधारक डेटा वातावरण से अलग (segmented) किया गया हो। PCI DSS v4.0 आपको सेग्मेंटेशन के माध्यम से दायरा कम करने की अनुमति देता है, लेकिन आपको यह साबित करना होगा कि यह काम करता है। आवश्यकता 11.4.5 के तहत कम से कम हर 12 महीने में सेग्मेंटेशन नियंत्रणों के पेनिट्रेशन परीक्षण की आवश्यकता होती है। यह निर्दिष्ट करें कि गेस्ट ट्रैफ़िक कभी भी भुगतान प्रणालियों से होकर न गुज़रे, और कैप्टिव पोर्टल पर कोई भी कार्ड डेटा दर्ज न किया जाए।

GDPR के तहत गेस्ट WiFi डेटा के लिए डेटा नियंत्रक कौन है?

आप आमतौर पर नियंत्रक होते हैं, और WiFi विक्रेता आपका प्रोसेसर होता है। इसलिए अनुबंध में उद्देश्य, सुरक्षा, उप-प्रोसेसरों, विलोपन और उल्लंघन अधिसूचना को कवर करने वाला अनुच्छेद 28 डेटा प्रोसेसिंग समझौता होना आवश्यक है। आपके RFP में निर्यात योग्य सहमति रिकॉर्ड और कॉन्फ़िगर योग्य अवधारण की भी आवश्यकता होनी चाहिए। अनुच्छेद 12(3) द्वारा निर्धारित एक महीने की समय सीमा के भीतर पहुंच और मिटाने के अनुरोधों का उत्तर देने के लिए टूल जोड़ें।

क्या हमें पहले दिन से Passpoint या OpenRoaming की आवश्यकता है?

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

क्या प्रोटेक्टिव DNS गेस्ट WiFi अनुबंध का हिस्सा होना चाहिए?

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

गेस्ट WiFi प्लेटफॉर्म बदलने से कितना व्यवधान होता है?

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

हम अपने AP वेंडर के प्लेटफॉर्म में निर्मित कैप्टिव पोर्टल का उपयोग क्यों न करें?

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