कर्मचारी WiFi कॅप्टिव्ह पोर्टल: कर्मचाऱ्यांना ऑनबोर्ड करणे आणि त्यांचे प्रमाणीकरण करणे

कर्मचारी WiFi कॅप्टिव्ह पोर्टल: कर्मचाऱ्यांना ऑनबोर्ड करणे आणि त्यांचे प्रमाणीकरण करणे एक Purple एंटरप्राइझ WiFi इंटेलिजन्स ब्रीफिंग [परिचय - अंदाजे १ मिनिट] Purple एंटरप्राइझ WiFi इंटेलिजन्स मालिकेत आपले स्वागत आहे. आज आपण सुरक्षा, HR ऑपरेशन्स आणि नेटवर्क आर्किटेक्चरच्या छेदनबिंदूवर असलेल्या एका विषयावर चर्चा करत आहोत: कर्मचारी WiFi कॅप्टिव्ह पोर्टल. आता, मला माहित आहे की तुमच्यापैकी काही जण काय विचार करत असतील. कर्मचाऱ्यांसाठी कॅप्टिव्ह पोर्टल? हे पाहुण्यांसाठी (guests) वापरले जात नाही का? आणि हाच तो गैरसमज आहे ज्याचे आपण सुरुवातीलाच निरसन करणे आवश्यक आहे. कर्मचारी WiFi कॅप्टिव्ह पोर्टल हे वेगळ्या लोगोसह पाहुण्यांचे स्प्लॅश पेज नाही. हे एक संरचित ऑनबोर्डिंग प्रवेशद्वार आहे जे वैयक्तिक कर्मचाऱ्यांचे प्रमाणीकरण करते, धोरण स्वीकृती लागू करते आणि तुमच्या ऑपरेशनल नेटवर्कवर प्रवेश देण्यापूर्वी उपकरणांची नोंदणी करते. हे योग्यरित्या केल्यास, तुम्ही बहुतांश एंटरप्राइझ WiFi उपयोजनांमधील सर्वात मोठी असुरक्षितता दूर करता: सामायिक केलेली pre-shared key. हे चुकीचे केल्यास, तुमचे माजी कर्मचारी, कंत्राटदार आणि वैयक्तिक उपकरणे तुमच्या कर्मचारी नेटवर्कवर अनिश्चित काळासाठी राहतील. चला आर्किटेक्चर समजून घेऊया. [तांत्रिक सखोल विश्लेषण - अंदाजे ५ मिनिटे] बहुतांश कर्मचारी WiFi उपयोजनांमधील मूलभूत समस्या म्हणजे सामायिक केलेला पासवर्ड. एकच WPA2 pre-shared key, जो बॅक ऑफिसमधील स्टिकी नोटवर लिहिलेला असतो, WhatsApp ग्रुपमध्ये सामायिक केला जातो आणि कोणीतरी सोडून गेल्यावर कधीही बदलला जात नाही. ८० कर्मचारी असलेल्या २०० खोल्यांच्या हॉटेलमध्ये, तो पासवर्ड अंदाजे ८० लोक, त्यांचे फोन घेणारे त्यांचे जोडीदार आणि किमान तीन माजी कर्मचाऱ्यांसह सामायिक केला गेला आहे. हे नेटवर्क नाही. हे एक उघडे दार आहे. कर्मचारी WiFi कॅप्टिव्ह पोर्टल सामायिक क्रेडेंशियलला ओळख-पडताळणी केलेल्या ऑनबोर्डिंग प्रवाहाने बदलून याचे निराकरण करते. हे प्रत्यक्षात कसे कार्य करते ते येथे आहे. जेव्हा एखादा नवीन कर्मचारी पहिल्यांदा त्यांचे उपकरण कर्मचारी नेटवर्कशी जोडतो, त्यांनी प्रोव्हिजनिंग SSID वर पोहोचतात. हे एक ओपन नेटवर्क आहे, परंतु ते एक वॉल गार्डन (walled garden) आहे - ते केवळ ऑनबोर्डिंग पोर्टल आणि तुमच्या ओळख प्रदात्याकडे मार्गस्थ करते. इतर कशाकडेही नाही. कर्मचाऱ्याला कॅप्टिव्ह पोर्टलवर रिडायरेक्ट केले जाते, जिथे ते त्यांच्या कॉर्पोरेट ओळखीचा वापर करून प्रमाणीकरण करतात. आजच्या बहुतांश एंटरप्राइझ वातावरणात, याचा अर्थ Microsoft Entra ID, Okta, किंवा Google Workspace द्वारे सिंगल साइन-ऑन (SSO) असा होतो. एकदा ओळख प्रदात्याने कर्मचारी सक्रिय असल्याचे आणि योग्य गटामध्ये असल्याची पुष्टी केली की, पोर्टल तुमच्या प्रमाणीकरण आर्किटेक्चरवर अवलंबून दोनपैकी एक गोष्ट करते. PEAP आणि MSCHAPv2 वापरून क्रेडेंशियल-आधारित उपयोजनात, पोर्टल क्रेडेंशियल्सची पडताळणी करते आणि नेटवर्क ॲक्सेस टोकन जारी करते. EAP-TLS वापरून प्रमाणपत्र-आधारित उपयोजनात, पोर्टल प्रमाणपत्र निर्मिती सुरू करते. तुमच्या Certificate Authority द्वारे एक उपकरण-विशिष्ट X.509 प्रमाणपत्र जारी केले जाते, जे कॉन्फिगरेशन प्रोफाइलमध्ये पॅकेज केले जाते - iOS वर dot-mobileconfig फाइल किंवा Android वर Passpoint प्रोफाइल - आणि उपकरणावर पाठवले जाते. उपकरण प्रोफाइल स्थापित करते, प्रोव्हिजनिंग SSID वरून डिस्कनेक्ट होते आणि EAP-TLS प्रमाणीकरणासाठी प्रमाणपत्र वापरून सुरक्षित कर्मचारी SSID शी स्वयंचलितपणे कनेक्ट होते. त्यानंतर, प्रत्येक वेळी जेव्हा उपकरण कर्मचारी नेटवर्कशी कनेक्ट होते, तेव्हा RADIUS सर्व्हर प्रमाणपत्राची पडताळणी करतो. कोणताही पासवर्ड प्रॉम्ट नाही. कोणतेही मॅन्युअल लॉगिन नाही. उपकरण फक्त शांतपणे आणि सुरक्षितपणे कनेक्ट होते. आता आपण बहुतांश एंटरप्राइझ उपयोजनांसाठी EAP-TLS हे लक्ष्य का आहे याबद्दल बोलूया. IEEE 802.1X मानक फ्रेमवर्क परिभाषित करते, परंतु EAP-TLS ही अशी पद्धत आहे जी प्रमाणीकरण मार्गातून क्रेडेंशियल चोरी पूर्णपणे काढून टाकते. फिशिंग करण्यासाठी कोणताही पासवर्ड नाही. ब्रूट-फोर्स करण्यासाठी कोणताही हॅश नाही. प्रमाणपत्र उपकरणाशी बांधील असते. उपकरण हरवल्यास किंवा चोरीला गेल्यास, तुम्ही तुमच्या Certificate Authority मधील प्रमाणपत्र रद्द करता आणि पुढील कनेक्शनच्या प्रयत्नात RADIUS सर्व्हर प्रवेश नाकारतो. कर्मचारी कंपनी सोडून गेल्यास, तुम्ही ओळख प्रदात्यामध्ये त्यांचे खाते अक्षम करता आणि प्रमाणपत्र त्या ओळखीच्या विरुद्ध जारी केले गेले असल्यामुळे, SCIM समाकलन स्वयंचलितपणे डी-प्रोव्हिजनिंग प्रसारित करते. व्यक्तीचा प्रवेश तो सोडून गेल्यावरच संपतो. This is the architecture that organisations like Premier Inn and Whitbread need when managing hundreds of properties with thousands of staff devices across a distributed estate. You cannot manage that at scale with shared passwords and manual revocation. आपण BYOD आयामावर देखील चर्चा करूया, कारण येथेच कॅप्टिव्ह पोर्टल विशेषतः मौल्यवान ठरते. बहुतांश हॉस्पिटॅलिटी, रिटेल आणि इव्हेंट वातावरणात, कर्मचाऱ्यांचा एक मोठा भाग ऑपरेशनल कामांसाठी वैयक्तिक उपकरणे वापरतो. हाउसकीपिंग कर्मचारी त्यांच्या स्वतःच्या स्मार्टफोनवर रूम असाइनमेंट तपासतात. रिटेल असोसिएट्स इन्व्हेंटरी शोधण्यासाठी वैयक्तिक टॅब्लेट वापरतात. स्टेडियम ऑपरेशन्स टीम संवादासाठी वैयक्तिक फोन वापरतात. ही अनमॅनेज्ड उपकरणे आहेत. तुम्ही त्यांची OS आवृत्ती, त्यांची अँटीव्हायरस स्थिती किंवा इतर कोणते ॲप्लिकेशन्स स्थापित आहेत हे नियंत्रित करत नाही. त्यांच्याकडे जास्तीत जास्त अर्ध-विश्वासू म्हणून पाहिले पाहिजे. कर्मचारी WiFi कॅप्टिव्ह पोर्टल प्रमाणीकरणानंतर या उपकरणांना समर्पित VLAN वर ठेवून BYOD हाताळते. VLAN त्यांना आवश्यक असलेल्या विशिष्ट अंतर्गत ॲप्लिकेशन्सचा ॲक्सेस देते - प्रॉपर्टी मॅनेजमेंट सिस्टम, पॉइंट-ऑफ-सेल इंटरफेस, शेड्यूलिंग ॲप - आणि इतर कशाचाही नाही. ते तुमच्या कॉर्पोरेट सर्व्हर्स, तुमच्या आर्थिक प्रणाली किंवा तुमच्या मॅनेज्ड उपकरण नेटवर्कपर्यंत पोहोचू शकत नाहीत. हे RADIUS पातळीवर लागू केलेले VLAN वर्गीकरण (segmentation) आहे आणि हे झिरो-ट्रस्ट तत्त्वाचे व्यावहारिक अंमलबजावणी आहे: ओळख सत्यापित करा, नंतर आवश्यक किमान प्रवेश द्या. आणखी एक आर्किटेक्चरल घटक कव्हर करण्यासारखा आहे: स्वीकार्य वापर धोरण, किंवा AUP. कॅप्टिव्ह पोर्टल हे AUP स्वीकृती लागू करण्यासाठी नैसर्गिक बिंदू आहे. कर्मचाऱ्याला स्टाफ नेटवर्कमध्ये प्रवेश मिळण्यापूर्वी, पोर्टल धोरण सादर करते - ज्यामध्ये स्वीकार्य वापर, देखरेख, डेटा हाताळणी आणि गैरवापराचे परिणाम समाविष्ट असतात - आणि स्पष्ट स्वीकृतीची आवश्यकता असते. हे धोरण स्वीकृतीची वेळ-नोंद केलेली, ऑडिट करण्यायोग्य नोंद तयार करते. GDPR अंतर्गत, हे महत्त्वाचे आहे. PCI-DSS अंतर्गत, कार्डधारक डेटाला स्पर्श करणाऱ्या कोणत्याही नेटवर्कसाठी, हे महत्त्वाचे आहे. आणि नेटवर्कच्या गैरवापराचा समावेश असलेल्या शिस्तभंगाच्या चौकशीच्या प्रसंगी, हे लक्षणीयरीत्या महत्त्वाचे ठरते. आता, बँडविड्थ. येथेच Purple Shield थेट संबंधित ठरते. उच्च-घनतेच्या कर्मचारी वातावरणात - गर्दीच्या वीकेंडला हॉटेल, Black Friday ला रिटेल इस्टेट, सामन्याच्या दिवशी स्टेडियम - स्टाफ नेटवर्कवरील बँडविड्थचा वाद हा एक खरा ऑपरेशनल प्रश्न असतो. Purple Shield DNS पातळीवर कार्य करते, जाहिरात पेलोड्स, ट्रॅकिंग स्क्रिप्ट्स आणि मालवेअर डोमेन्स उपकरणापर्यंत पोहोचण्यापूर्वीच ब्लॉक करते. Purple च्या स्वतःच्या डेटानुसार, याचा व्यावहारिक परिणाम म्हणजे संपूर्ण नेटवर्कवरील एकूण डाउनलोड केलेल्या डेटामध्ये ४०% पर्यंत घट होते. कर्मचारी उपकरणांसाठी, याचा अर्थ जलद पेज लोड, उपकरणाचा कमी बॅटरी वापर आणि ऑपरेशनल ट्रॅफिकसाठी अधिक उपलब्ध बँडविड्थ असा होतो. पेजेस ३.५ पट वेगाने लोड होतात जेव्हा जाहिरातींनी भरलेल्या पेजच्या वैशिष्ट्यपूर्ण १२० पेक्षा जास्त DNS क्वेरी नेटवर्कवर पोहोचण्यापूर्वी काढून टाकल्या जातात. तुम्हाला हार्डवेअरला स्पर्श न करता, ॲक्सेस पॉइंट्स रीकॉन्फिगर न करता आणि कोणत्याही प्रति-उपकरण सेटअपशिवाय ही सुधारणा मिळते. [अंमलबजावणीच्या शिफारसी आणि त्रुटी - अंदाजे २ मिनिटे] मी तुम्हाला अंमलबजावणीचा क्रम आणि लक्ष ठेवण्याच्या बिघाड मोड्स सांगतो. एकही ॲक्सेस पॉइंट कॉन्फिगर करण्यापूर्वी तुमच्या VLAN आर्किटेक्चरपासून सुरुवात करा. किमान तीन VLAN परिभाषित करा: कर्मचारी, पाहुणे (guest) आणि IoT. तुमची फायरवॉल धोरणे मॅप करा. तुमच्या सुरक्षा टीमकडून मंजुरी मिळवा. WiFi उपयोजनांमधील सर्वात महागड्या चुका तेव्हा होतात जेव्हा नेटवर्क आधी तयार केले जाते आणि सुरक्षा आर्किटेक्चर नंतर जोडले जाते. दुसरे, तुमच्या RADIUS पायाभूत सुविधा रिडंडन्सीसह तैनात करा. एकाच RADIUS सर्व्हरच्या बिघाडामुळे प्रत्येक कर्मचारी एकाच वेळी नेटवर्कवरून बाहेर फेकला जातो. हॉटेलमध्ये, याचा अर्थ फ्रंट डेस्क चेक-इन प्रक्रिया करू शकत नाही. रिटेल स्टोअरमध्ये, याचा अर्थ पॉइंट-ऑफ-सेल सिस्टम प्रमाणीकरण करू शकत नाहीत. ॲक्टिव्ह-पॅसिव्ह कॉन्फग्युरेशनमध्ये किमान दोन RADIUS सर्व्हर्स तैनात करा आणि लाइव्ह जाण्यापूर्वी फेलओव्हरची चाचणी घ्या. तिसरे, तुमचा RADIUS सर्व्हर LDAP किंवा SAML द्वारे तुमच्या ओळख प्रदात्याशी समाकलित करा. यामुळेच स्वयंचलित डीप्रोव्हिजनिंग सक्षम होते. जेव्हा एखाद्या कर्मचाऱ्याला Microsoft Entra ID किंवा Okta मध्ये अक्षम केले जाते, तेव्हा RADIUS सर्व्हर पुढील कनेक्शनच्या प्रयत्नात त्यांचे क्रेडेंशियल्स किंवा त्यांचे प्रमाणपत्र स्वीकारणे बंद करतो. कोणतीही मॅन्युअल पायरी नाही, कोणतीही तिकीट रांग नाही, कंपनी सोडणे आणि प्रवेश काढून घेणे यामध्ये कोणताही फरक नाही. चौथे, तुमच्या टीममधील सर्वात कमी तांत्रिक वापरकर्त्यासाठी तुमचे कॅप्टिव्ह पोर्टल ऑनबोर्डिंग प्रवाह डिझाइन करा. IT व्यवस्थापकासाठी नाही. हंगामी वेअरहाउस कर्मचारी ज्याने कधीही कॉन्फिगरेशन प्रोफाइल स्थापित केलेले नाही. स्पष्ट सूचना, ब्रँडेड इंटरफेस आणि प्रत्येक स्क्रीनवर दिसणारा हेल्पडेस्क संपर्क क्रमांक. आता त्रुटी. सर्वात सामान्य बिघाड मोड म्हणजे वॉल गार्डन (walled garden) खूप मोकळे असणे. जर तुमचे प्रोव्हिजनिंग SSID सामान्य इंटरनेट ॲक्सेसला अनुमती देत असेल, तर कर्मचारी ऑनबोर्डिंग प्रवाह पूर्ण करण्याऐवजी फक्त त्यावरच राहतील. ते पोर्टल, ओळख प्रदाता एंडपॉइंट्स आणि प्रमाणपत्र डाउनलोड सर्व्हरपुरते मर्यादित करा. इतर काहीही नाही. दुसरी त्रुटी म्हणजे Android फ्रॅगमेंटेशन. iOS dot-mobileconfig प्रोफाइल सुसंगतपणे हाताळते. Android तसे करत नाही. विविध उत्पादक आणि OS आवृत्त्या WiFi प्रोफाइल आणि प्रमाणपत्र स्थापना वेगवेगळ्या प्रकारे हाताळतात. तुम्ही रोलआउट करण्यापूर्वी तुमच्या कर्मचाऱ्यांनी प्रत्यक्षात वापरलेल्या विशिष्ट Android उपकरणांवर तुमच्या ऑनबोर्डिंग प्रवाहाची चाचणी घ्या. Passpoint, ज्याला Hotspot 2.0 म्हणून देखील ओळखले जाते, प्रारंभिक सेटअपनंतर स्वयंचलित नेटवर्क शोध आणि प्रमाणीकरण सक्षम करून Android अनुभव लक्षणीयरीत्या सुधारते. तिसरी त्रुटी म्हणजे प्रमाणपत्राची मुदत संपणे. अल्पायुषी प्रमाणपत्रे जारी करा - BYOD उपकरणांसाठी ९० दिवस हा एक वाजवी डीफॉल्ट आहे. जेव्हा प्रमाणपत्राची मुदत संपते, तेव्हा उपकरणाने पोर्टलद्वारे पुन्हा ऑनबोर्ड करणे आवश्यक आहे. हे नैसर्गिकरित्या नेटवर्कमधून जुनी उपकरणे काढून टाकते आणि वर्तमान ओळख प्रदाता स्थितीच्या विरुद्ध पुन्हा प्रमाणीकरण करण्यास भाग पाडते. सहा महिन्यांपूर्वी खाते अक्षम केलेल्या माजी कर्मचाऱ्याचे उपकरण स्वयंचलितपणे पुन्हा ऑनबोर्ड होण्यात अपयशी ठरेल. [रॅपिड-फायर प्रश्नोत्तरे - अंदाजे १ मिनिट] आम्ही वारंवार ऐकणारे काही प्रश्न. "आम्ही पूर्ण 802.1X ऐवजी iPSK वापरू शकतो का?" होय, अशा वातावरणासाठी जिथे प्रमाणपत्र उपयोजन व्यवहार्य नाही. iPSK, किंवा Identity Pre-Shared Key, प्रत्येक वापरकर्त्याला किंवा उपकरणाला एक अद्वितीय WiFi पासवर्ड नियुक्त करते. हे सामायिक केलेल्या PSK पेक्षा अधिक सुरक्षित आहे कारण प्रत्येक क्रेडेंशियल वैयक्तिक आणि रद्द करण्यायोग्य असते. हे EAP-TLS पेक्षा कमी सुरक्षित आहे कारण ते अजूनही पासवर्ड-आधारित आहे. याचा वापर एक पायरी म्हणून करा, अंतिम ध्येय म्हणून नाही. "आम्ही आधीच WPA2-Enterprise वर असल्यास आम्हाला WPA3 ची आवश्यकता आहे का?" जर तुमचे हार्डवेअर याला सपोर्ट करत असेल, तर होय. WPA3-Enterprise 'Simultaneous Authentication of Equals' सादर करते, जे हँडशेक विरुद्ध ऑफलाइन डिक्शनरी हल्ले दूर करते. सपोर्टेड हार्डवेअरवरील स्थलांतर खर्च हा केवळ कॉन्फिगरेशन बदल आहे. सुरक्षेतील वाढ महत्त्वपूर्ण आहे. "ज्या कंत्राटदारांकडे कॉर्पोरेट ओळख नाही त्यांना आम्ही कसे हाताळू?" iPSK किंवा पोर्टलद्वारे जारी केलेले वेळ-मर्यादित पाहुणे (guest) क्रेडेंशियल वापरा. कराराच्या समाप्ती तारखेशी जुळणारी कालबाह्यता तारीख सेट करा. Purple चे प्लॅटफॉर्म मूळतः वेळ-मर्यादित प्रवेश क्रेडेंशियल्सना सपोर्ट करते. [सारांश आणि पुढील पावले - अंदाजे १ मिनिट] चला याचा सारांश घेऊया. कर्मचारी WiFi कॅप्टिव्ह पोर्टल हे केवळ सोयीचे वैशिष्ट्य नाही. हे तुमच्या ऑपरेशनल नेटवर्कवर ओळख पडताळणी, धोरण स्वीकृती, उपकरण नोंदणी आणि प्रवेश नियंत्रणासाठी अंमलबजावणीचे बिंदू आहे. सामायिक केलेली pre-shared key ही अनुपालन दायित्व आणि सुरक्षेची असुरक्षितता आहे. त्याला ओळख-सत्यापित ऑनबोर्डिंग प्रवाह, VLAN वर्गीकरण आणि RADIUS-आधारित प्रमाणीकरणासह बदला. तुमची त्वरित पुढील पावले: तुमच्या वर्तमान कर्मचारी नेटवर्क प्रमाणीकरण पद्धतीचे ऑडिट करा. जर तुम्ही सामायिक PSK चालवत असाल, तर ते तुमचे सर्वोच्च प्राधान्य सुधारणा काम आहे. जर तुम्ही क्रेडेंशियल-आधारित 802.1X वर असाल, तर प्रमाणपत्र-आधारित EAP-TLS च्या मार्गाचे मूल्यांकन करा. आणि जर तुमच्या कर्मचारी नेटवर्कवर Purple Shield तैनात नसेल, तर केवळ बँडविड्थ कपातच या संभाषणाचे समर्थन करते. ८०,००० पेक्षा जास्त थेट ठिकाणांवरील Purple च्या उपयोजनांमधील अंमलबजावणी मार्गदर्शन, आर्किटेक्चर टेम्पलेट्स आणि केस स्टडीजसाठी, purple.ai ला भेट द्या. ऐकल्याबद्दल धन्यवाद.