कर्मचारी WiFi Captive Portal: कर्मचाऱ्यांना ऑनबोर्ड करणे आणि प्रमाणित करणे

कर्मचारी WiFi Captive Portal: कर्मचाऱ्यांचे ऑनबोर्डिंग आणि प्रमाणीकरण (Authentication) एक Purple Enterprise WiFi Intelligence ब्रीफिंग [प्रस्तावना - अंदाजे १ मिनिट] Purple Enterprise WiFi Intelligence मालिकेत आपले स्वागत आहे. आज आपण सुरक्षा, HR ऑपरेशन्स आणि नेटवर्क आर्किटेक्चरच्या केंद्रस्थानी असलेल्या एका विषयावर चर्चा करत आहोत: कर्मचारी WiFi captive portal. आता, मला माहित आहे की तुमच्यापैकी काही जण काय विचार करत असतील. कर्मचाऱ्यांसाठी captive portal? ते तर पाहुण्यांसाठी (guests) वापरले जाते ना? आणि हाच तो गैरसमज आहे जो आपल्याला सुरुवातीलाच दूर करणे आवश्यक आहे. कर्मचारी WiFi captive portal म्हणजे फक्त वेगळा लोगो असलेले गेस्ट स्प्लॅश पेज नाही. हे एक पद्धतशीर ऑनबोर्डिंग गेटवे आहे जे वैयक्तिक कर्मचाऱ्यांचे प्रमाणीकरण (authenticate) करते, पॉलिसी स्वीकृती लागू करते आणि तुमच्या ऑपरेशनल नेटवर्कमध्ये प्रवेश देण्यापूर्वी उपकरणांची नोंदणी करते. हे योग्य पद्धतीने केल्यास, तुम्ही बऱ्याच एंटरप्राइझ WiFi उपयोजनांमधील सर्वात मोठी असुरक्षितता दूर करता: सामायिक केलेले प्री-शेअर्ड की (shared pre-shared key). आणि हे चुकीचे केल्यास, माजी कर्मचारी, कंत्राटदार आणि वैयक्तिक उपकरणे तुमच्या कर्मचारी नेटवर्कवर अनिश्चित काळासाठी पडून राहतील. चला, आता आर्किटेक्चर समजून घेऊया. [तांत्रिक सखोल माहिती - अंदाजे ५ मिनिटे] बऱ्याच कर्मचारी WiFi उपयोजनांमधील पायाभूत समस्या म्हणजे सामायिक केलेला पासवर्ड. एकच WPA2 प्री-शेअर्ड की, जी बॅक ऑफिसमधील स्टिकी नोटवर लिहिलेली असते, WhatsApp ग्रुपवर शेअर केली जाते आणि कोणीतरी नोकरी सोडल्यावर कधीही बदलली जात नाही. ८० कर्मचारी असलेल्या २०० खोल्यांच्या हॉटेलमध्ये, तो पासवर्ड साधारणपणे ८० लोक, त्यांचे फोन वापरणारे त्यांचे जोडीदार आणि किमान तीन माजी कर्मचाऱ्यांसोबत शेअर केला गेलेला असतो. ते नेटवर्क नाही. तो तर एक उघडा दरवाजा आहे. कर्मचारी WiFi captive portal सामायिक केलेल्या क्रेडेंशियलऐवजी ओळख-प्रमाणित (identity-verified) ऑनबोर्डिंग प्रवाहाचा वापर करून ही समस्या सोडवते. हे प्रत्यक्षात कसे कार्य करते ते येथे दिले आहे. जेव्हा एखादा नवीन कर्मचारी पहिल्यांदा आपले उपकरण कर्मचारी नेटवर्कशी जोडतो, तेव्हा तो प्रोव्हिजनिंग SSID वर पोहोचतो. हे एक ओपन नेटवर्क आहे, परंतु ते एका सुरक्षित भिंतीच्या आत असते (walled garden) - हे केवळ ऑनबोर्डिंग पोर्टल आणि तुमच्या आयडेंटिटी प्रोव्हायडरकडे मार्ग निर्देशित करते. इतर कशाकडेही नाही. कर्मचाऱ्याला captive portal वर रिडायरेक्ट केले जाते, जिथे ते त्यांच्या कॉर्पोरेट ओळखीचा वापर करून प्रमाणीकरण (authenticate) करतात. आजच्या बहुतांश एंटरप्राइझ वातावरणात, याचा अर्थ Microsoft Entra ID, Okta किंवा Google Workspace द्वारे सिंगल साइन-ऑन (Single Sign-On) असा होतो. एकदा आयडेंटिटी प्रोव्हायडरने कर्मचारी सक्रिय असल्याचे आणि योग्य ग्रुपमध्ये असल्याचे कन्फर्म केले की, पोर्टल तुमच्या प्रमाणीकरण (authentication) आर्किटेक्चरनुसार दोनपैकी एक गोष्ट करते. PEAP आणि MSCHAPv2 वापरणाऱ्या क्रेडेंशियल-आधारित उपयोजनात, पोर्टल क्रेडेंशियल्स प्रमाणित करते आणि नेटवर्क ॲक्सेस टोकन जारी करते. EAP-TLS वापरणाऱ्या सर्टिफिकेट-आधारित उपयोजनात, पोर्टल सर्टिफिकेट निर्मितीला गती देते. तुमच्या सर्टिफिकेट ऑथॉरिटीद्वारे एका विशिष्ट उपकरणासाठी X.509 सर्टिफिकेट जारी केले जाते, जे कॉन्फिगरेशन प्रोफाइलमध्ये पॅकेज केले जाते - iOS वर dot-mobileconfig फाईल किंवा Android वर Passpoint प्रोफाइल - आणि उपकरणावर पाठवले जाते. उपकरण ते प्रोफाइल इन्स्टॉल करते, प्रोव्हिजनिंग SSID वरून डिस्कनेक्ट होते आणि EAP-TLS प्रमाणीकरणासाठी त्या सर्टिफिकेटचा वापर करून सुरक्षित कर्मचारी SSID शी आपोआप कनेक्ट होते. त्या क्षणापासून पुढे, प्रत्येक वेळी जेव्हा डिव्हाइस स्टाफ नेटवर्कशी कनेक्ट होते, तेव्हा RADIUS सर्व्हर प्रमाणपत्राची पडताळणी करतो. कोणताही पासवर्ड प्रॉम्ट नाही. कोणतेही मॅन्युअल लॉगिन नाही. डिव्हाइस अगदी शांतपणे आणि सुरक्षितपणे कनेक्ट होते. आता आपण याबद्दल बोलूया की बहुतांश एंटरप्राइझ उपयोजनांसाठी EAP-TLS हे लक्ष्यित स्थान का आहे. IEEE 802.1X मानक फ्रेमवर्क परिभाषित करते, परंतु EAP-TLS ही अशी पद्धत आहे जी प्रमाणीकरण मार्गातून क्रेडेंशियल चोरी पूर्णपणे काढून टाकते. फिश करण्यासाठी कोणताही पासवर्ड नाही. ब्रूट-फोर्स करण्यासाठी कोणताही हॅश नाही. प्रमाणपत्र डिव्हाइसशी बांधील असते. डिव्हाइस हरवले किंवा चोरीला गेले तर, तुम्ही तुमच्या Certificate Authority मध्ये प्रमाणपत्र रद्द करता आणि RADIUS सर्व्हर पुढील कनेक्शनच्या प्रयत्नात प्रवेश नाकारतो. जर कर्मचारी कंपनी सोडत असेल, तर तुम्ही आयडेंटिटी प्रोव्हाइडरमध्ये त्यांचे खाते निष्क्रिय करता, आणि प्रमाणपत्र त्या ओळखीच्या विरुद्ध जारी केले गेले असल्याने, SCIM इंटिग्रेशन ऑटोमॅटिकली डीप्रॉव्हिजनिंग प्रसारित करते. व्यक्तीचा प्रवेश तेव्हाच संपतो जेव्हा तिचा कंपनीशी संबंध संपतो. Premier Inn आणि Whitbread सारख्या संस्थांना एका विखुरलेल्या मालमत्तेवर हजारो स्टाफ डिव्हाइसेससह शेकडो प्रॉपर्टीज व्यवस्थापित करताना याच आर्किटेक्चरची आवश्यकता असते. तुम्ही सामायिक केलेले पासवर्ड आणि मॅन्युअल रिव्होकेशनद्वारे मोठ्या प्रमाणावर याचे व्यवस्थापन करू शकत नाही. आपण BYOD च्या पैलूवर देखील चर्चा करूया, कारण येथेच Captive Portal विशेषतः मूल्यवान ठरते. बहुतांश हॉस्पिटॅलिटी, रिटेल आणि इव्हेंट वातावरणात, कर्मचारी वर्गाचा एक मोठा हिस्सा ऑपरेशनल कामांसाठी वैयक्तिक डिव्हाइसेस वापरतो. हाऊसकीपिंग कर्मचारी त्यांच्या स्वतःच्या स्मार्टफोनवर रूम असाइनमेंट तपासतात. रिटेल असोसिएट्स इन्व्हेंटरी शोधण्यासाठी वैयक्तिक टॅब्लेट वापरतात. स्टेडियम ऑपरेशन्स टीम संवादासाठी वैयक्तिक फोन वापरतात. ही अनमॅनेज्ड डिव्हाइसेस आहेत. तुम्ही त्यांच्या OS व्हर्जनवर, त्यांच्या अँटीव्हायरस स्थितीवर किंवा इतर कोणते ॲप्लिकेशन्स इन्स्टॉल आहेत यावर नियंत्रण ठेवत नाही. त्यांच्याकडे जास्तीत जास्त अर्ध-विश्वासू म्हणून पाहिले पाहिजे. स्टाफ WiFi Captive Portal ऑथेंटिकेशननंतर या डिव्हाइसेसना एका समर्पित VLAN वर ठेवून BYOD हाताळते. VLAN त्यांना आवश्यक असलेल्या विशिष्ट अंतर्गत ॲप्लिकेशन्सचा प्रवेश देते - जसे की प्रॉपर्टी मॅनेजमेंट सिस्टम, पॉइंट-ऑफ-सेल इंटरफेस, शेड्युलिंग ॲप - आणि इतर काहीही नाही. ते तुमच्या कॉर्पोरेट सर्व्हर्स, तुमच्या आर्थिक प्रणाली किंवा तुमच्या मॅनेज्ड डिव्हाइस नेटवर्कपर्यंत पोहोचू शकत नाहीत. हे RADIUS स्तरावर लागू केलेले VLAN सेगमेंटेशन आहे आणि ते झिरो-ट्रस्ट तत्त्वाची व्यावहारिक अंमलबजावणी आहे: ओळख सत्यापित करा, नंतर आवश्यक किमान प्रवेश द्या. आणखी एका आर्किटेक्चरल घटकाचा समावेश करणे आवश्यक आहे: स्वीकार्य वापर धोरण (Acceptable Use Policy), किंवा AUP. Captive Portal हे AUP मंजुरीची अंमलबजावणी करण्यासाठीचे सर्वात सोपे आणि योग्य ठिकाण आहे. कर्मचाऱ्याला स्टाफ नेटवर्कमध्ये प्रवेश मिळण्यापूर्वी, हे पोर्टल धोरण दर्शवते - ज्यामध्ये स्वीकार्य वापर, मॉनिटरिंग, डेटा हाताळणी आणि गैरवापराचे परिणाम समाविष्ट असतात - आणि यासाठी स्पष्ट संमती आवश्यक असते. हे धोरण स्वीकारल्याची वेळेची नोंद असलेले आणि ऑडिट करता येण्याजोगे रेकॉर्ड तयार करते. GDPR अंतर्गत याला महत्त्व आहे. PCI DSS अंतर्गत, कार्डधारकाच्या डेटाला स्पर्श करणाऱ्या कोणत्याही नेटवर्कसाठी हे महत्त्वाचे आहे. आणि नेटवर्कच्या गैरवापराशी संबंधित शिस्तभंगाच्या चौकशीच्या वेळी, याला प्रचंड महत्त्व प्राप्त होते. आता, बँडविड्थबद्दल पाहू. येथेच Purple Shield थेट संबंधित ठरते. उच्च-घनतेच्या कर्मचारी वातावरणात - उदाहरणार्थ, वीकेंडला पूर्ण भरलेल्या हॉटेलमध्ये, ब्लॅक फ्रायडेच्या दिवशी रिटेल इस्टेटमध्ये किंवा मॅचच्या दिवशी स्टेडियममध्ये - स्टाफ नेटवर्कवरील बँडविड्थची स्पर्धा ही एक खरी ऑपरेशनल समस्या असते. Purple Shield हे DNS स्तरावर कार्य करते, जाहिरातींचे पेलोड्स, ट्रॅकिंग स्क्रिप्ट्स आणि मालवेअर डोमेन्स डिव्हाइसपर्यंत पोहोचण्यापूर्वीच ब्लॉक करते. Purple च्या स्वतःच्या डेटानुसार, याचा व्यावहारिक परिणाम म्हणजे संपूर्ण नेटवर्कवरील एकूण डाउनलोड केलेल्या डेटामध्ये ४०% पर्यंत घट होते. कर्मचाऱ्यांच्या डिव्हाइसेससाठी, याचा अर्थ जलद पेज लोड, कमी बॅटरी वापर आणि ऑपरेशनल ट्रॅफिकसाठी अधिक बँडविड्थ उपलब्ध असणे असा होतो. जाहिरातींनी भरलेल्या पेजवर सामान्यतः असणाऱ्या १२० हून अधिक DNS क्वेरीज नेटवर्कवर येण्यापूर्वीच काढून टाकल्या जातात, तेव्हा पेजेस ३.५ पटीने वेगाने लोड होतात. तुम्हाला ही सुधारणा हार्डवेअरला स्पर्श न करता, ॲक्सेस पॉइंट्स पुन्हा कॉन्फिगर न करता आणि कोणत्याही डिव्हाइस-निहाय सेटअपशिवाय मिळते. [अंमलबजावणीच्या शिफारसी आणि धोके - साधारणपणे २ मिनिटे] मी तुम्हाला अंमलबजावणीचा क्रम आणि ज्या त्रुटींकडे लक्ष दिले पाहिजे त्याबद्दल सांगतो. एकही ॲक्सेस पॉइंट कॉन्फिगर करण्यापूर्वी तुमच्या VLAN आर्किटेक्चरपासून सुरुवात करा. किमान तीन VLANs परिभाषित करा: स्टाफ, गेस्ट आणि IoT. तुमच्या फायरवॉल पॉलिसी मॅप करा. तुमच्या सुरक्षा टीमकडून मंजुरी मिळवा. WiFi उपयोजनांमधील सर्वात महागड्या चुका तेव्हा होतात जेव्हा नेटवर्क आधी तयार केले जाते आणि सुरक्षा आर्किटेक्चर नंतर जोडले जाते. दुसरे म्हणजे, तुमच्या RADIUS इन्फ्रास्ट्रक्चरची रेडंडन्सीसह अंमलबजावणी करा. एकच RADIUS सर्व्हर निकामी झाल्यास सर्व कर्मचारी एकाच वेळी नेटवर्कमधून बाहेर फेकले जातात. हॉटेलमध्ये, याचा अर्थ असा की फ्रंट डेस्क चेक-इन प्रक्रिया करू शकत नाही. रिटेल स्टोअरमध्ये, याचा अर्थ पॉइंट-ऑफ-सेल सिस्टम ऑथेंटिकेट करू शकत नाहीत. ॲक्टिव्ह-पॅसिव्ह कॉन्फिगरेशनमध्ये किमान दोन RADIUS सर्व्हर वापरा आणि लाईव्ह जाण्यापूर्वी फेलओव्हरची चाचणी घ्या. तिसरे म्हणजे, LDAP किंवा SAML द्वारे तुमच्या RADIUS सर्व्हरला तुमच्या आयडेंटिटी प्रोव्हाइडरशी इंटिग्रेट करा. यामुळेच ऑटोमॅटिक डीप्रोव्हिजनिंग सक्षम होते. जेव्हा एखाद्या कर्मचाऱ्याला Microsoft Entra ID किंवा Okta मध्ये डिसेबल केले जाते, तेव्हा RADIUS सर्व्हर पुढील कनेक्शनच्या प्रयत्नात त्यांची क्रेडेन्शियल किंवा त्यांचे सर्टिफिकेट स्वीकारणे बंद करतो. कोणतीही मॅन्युअल पायरी नाही, कोणतीही तिकीट रांग नाही, आणि कर्मचारी सोडणे व ॲक्सेस काढून घेणे यामध्ये कोणताही वेळ वाया जात नाही. चौथे, तुमच्या टीममधील सर्वात कमी तांत्रिक ज्ञान असलेल्या युझरसाठी तुमचा Captive Portal ऑनबोर्डिंग फ्लो डिझाइन करा. IT मॅनेजरसाठी नाही. तर तो हंगामी वेअरहाउस ऑपरेटिव्ह ज्याने कधीही कॉन्फिगरेशन प्रोफाइल इंस्टॉल केलेले नाही. स्पष्ट सूचना, ब्रँडेड इंटरफेस आणि प्रत्येक स्क्रीनवर हेल्पडेस्क संपर्क क्रमांक स्पष्टपणे दिसणे आवश्यक आहे. आता धोके पाहूयात. सर्वात सामान्य बिघाड हा 'walled garden' खूप जास्त परवानगी देणारा असणे हा आहे. जर तुमचे प्रोव्हिजनिंग SSID सामान्य इंटरनेट प्रवेशाची परवानगी देत असेल, तर कर्मचारी ऑनबोर्डिंग फ्लो पूर्ण करण्याऐवजी त्यावरच राहतील. त्याला फक्त पोर्टल, आयडेंटिटी प्रोव्हायडर एंडपॉइंट्स आणि सर्टिफिकेट डाउनलोड सर्व्हरपुरते मर्यादित करा. इतर काहीही नाही. दुसरा धोका म्हणजे Android फ्रॅगमेंटेशन. iOS हे dot-mobileconfig प्रोफाइल सुसंगतपणे हाताळते. Android तसे करत नाही. भिन्न उत्पादक आणि OS व्हर्जन सर्टिफिकेट इन्स्टॉलेशन वेगवेगळ्या पद्धतीने हाताळतात. तुम्ही सेवा सुरू करण्यापूर्वी, तुमच्या कर्मचाऱ्यांद्वारे प्रत्यक्षात वापरल्या जाणाऱ्या विशिष्ट Android डिव्हाइसेसवर तुमच्या ऑनबोर्डिंग फ्लोची चाचणी घ्या. Passpoint, ज्याला Hotspot 2.0 म्हणूनही ओळखले जाते, सुरुवातीच्या सेटअप नंतर स्वयंचलित नेटवर्क शोध आणि ऑथेंटिकेशन सक्षम करून Android अनुभव लक्षणीयरित्या सुधारते. तिसरा धोका म्हणजे सर्टिफिकेटची मुदत संपणे (certificate expiry). कमी मुदतीचे सर्टिफिकेट्स जारी करा - BYOD डिव्हाइसेससाठी ९० दिवस हा एक वाजवी डीफॉल्ट कालावधी आहे. जेव्हा सर्टिफिकेटची मुदत संपते, तेव्हा डिव्हाइसने पोर्टलद्वारे पुन्हा ऑनबोर्ड केले पाहिजे. हे साहजिकच नेटवर्कवरून जुने डिव्हाइसेस काढून टाकते आणि सध्याच्या आयडेंटिटी प्रोव्हायडरच्या स्थितीनुसार पुन्हा ऑथेंटिकेशन करण्यास भाग पाडते. सहा महिन्यांपूर्वी खाते अक्रिय (disabled) केलेल्या माजी कर्मचाऱ्याचे डिव्हाइस आपोआप पुन्हा ऑनबोर्डिंगमध्ये अयशस्वी होईल. [रॅपिड-फायर प्रश्नोत्तरे - साधारण १ मिनिट] आम्हाला वारंवार विचारले जाणारे काही प्रश्न येथे आहेत. "आम्ही संपूर्ण 802.1X ऐवजी iPSK वापरू शकतो का?" होय, अशा वातावरणासाठी जेथे सर्टिफिकेट डिप्लॉयमेंट व्यवहार्य नाही. iPSK, किंवा Identity Pre-Shared Key, प्रत्येक युझर किंवा डिव्हाइसला एक युनिक WiFi पासवर्ड नियुक्त करतो. हे सामायिक केलेल्या PSK पेक्षा अधिक सुरक्षित आहे कारण प्रत्येक क्रेडेंशियल वैयक्तिक आणि रद्द करण्यायोग्य असते. हे EAP-TLS पेक्षा कमी सुरक्षित आहे कारण ते अद्याप पासवर्ड-आधारित आहे. याचा वापर अंतिम उद्दिष्ट म्हणून नव्हे, तर प्रवासातील एक टप्पा म्हणून करा. "आम्ही आधीच WPA2-Enterprise वर असल्यास आम्हाला WPA3 ची आवश्यकता आहे का?" जर तुमचे हार्डवेअर याला सपोर्ट करत असेल, तर होय. WPA3-Enterprise 'Simultaneous Authentication of Equals' सादर करते, जे हँडशेक विरुद्ध होणारे ऑफलाइन डिक्शनरी अटॅक्स काढून टाकते. सपोर्टेड हार्डवेअरवर मायग्रेशनचा खर्च हा केवळ एक कॉन्फिगरेशन बदल आहे. यातील सुरक्षा सुधारणा अत्यंत महत्त्वपूर्ण आहे. "आम्ही कॉर्पोरेट ओळख (corporate identity) नसलेल्या कंत्राटदारांना कसे हाताळावे?" iPSK किंवा पोर्टलद्वारे जारी केलेले मर्यादित कालावधीचे गेस्ट क्रेडेंशियल वापरा. कंत्राट समाप्ती तारखेशी सुसंगत असणारी एक्स्पायरी तारीख सेट करा. Purple चे प्लॅटफॉर्म अशा कालबद्ध प्रवेश क्रेडेंशियलला नेटिव्हली सपोर्ट करते. [सारांश आणि पुढील पावले - साधारण १ मिनिट] याची थोडक्यात सांगता करूया. स्टाफ WiFi Captive Portal हे केवळ सोयीचे वैशिष्ट्य नाही. हे तुमच्या ऑपरेशनल नेटवर्कवरील ओळख पडताळणी, पॉलिसी स्वीकृती, डिव्हाइस नोंदणी आणि प्रवेश नियंत्रणासाठी अंमलबजावणीचे मुख्य ठिकाण आहे. सामायिक प्री-शेअर्ड की (shared PSK) ही अनुपालनाचे दायित्व आणि एक सुरक्षा असुरक्षितता आहे. त्याऐवजी ओळख-पडताळणी असलेला ऑनबोर्डिंग फ्लो, VLAN विभागणी आणि RADIUS-आधारित प्रमाणीकरण वापरा. तुमची तात्काळ पुढील पावले: तुमच्या सध्याच्या स्टाफ नेटवर्क प्रमाणीकरण पद्धतीचे ऑडिट करा. तुम्ही सामायिक PSK वापरत असल्यास, ती दुरुस्त करणे हे तुमचे सर्वोच्च प्राधान्य असले पाहिजे. तुम्ही क्रेडेंशियल-आधारित 802.1X वर असल्यास, प्रमाणपत्र-आधारित EAP-TLS कडे जाण्याच्या मार्गाचे मूल्यांकन करा. आणि जर तुमच्या स्टाफ नेटवर्कवर Purple Shield तैनात नसेल, तर केवळ बँडविड्थची होणारी बचतच या विषयावर चर्चा करण्यासाठी पुरेशी आहे. अंमलबजावणी मार्गदर्शन, आर्किटेक्चर टेम्पलेट्स आणि ८०,००० हून अधिक थेट ठिकाणांवरील Purple च्या उपयोजनांमधील केस स्टडीजसाठी, purple.ai ला भेट द्या. ऐकल्याबद्दल धन्यवाद.