How to Configure SCEP for Secure Enterprise WiFi and BYOD Provisioning

Purple कडून या तांत्रिक ब्रीफिंगमध्ये आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण सुरक्षित एंटरप्राइझ WiFi आणि BYOD प्रोव्हिजनिंगसाठी SCEP च्या कॉन्फिगरेशनचा सखोल अभ्यास करणार आहोत. हॉस्पिटॅलिटी, रिटेल आणि सार्वजनिक क्षेत्रांमध्ये कार्यरत असलेल्या IT मॅनेजर्स, नेटवर्क आर्किटेक्ट्स आणि CTOs साठी, नेटवर्क ॲक्सेस व्यवस्थापित करणे हा सुरक्षा आणि ऑपरेशनल कार्यक्षमता यामधील एक सततचा समतोल आहे. तुम्ही दररोज तुमच्या नेटवर्कशी कनेक्ट होणाऱ्या शेकडो, कधीकधी हजारो डिव्हाइसेस हाताळत आहात. कर्मचाऱ्यांचे स्मार्टफोन, कंत्राटदारांचे लॅपटॉप, पॉइंट-ऑफ-सेल टॅब्लेट. आणि हे हाताळण्याचे जुने मार्ग आता पुरेसे राहिलेले नाहीत. कर्मचारी आणि BYOD WiFi साठी प्री-शेअर्ड की किंवा PSKs वर अवलंबून राहणे ही एक सुरक्षा असुरक्षितता आहे ज्याचा गैरफायदा घेतला जाऊ शकतो. एक शेअर्ड पासवर्ड, एकदा तडजोड झाली की, कोणालाही तुमच्या नेटवर्कमध्ये प्रवेश देतो. आणि MAC ऑथेंटिकेशन बायपास किंवा MAB देखील काही चांगले नाही. आधुनिक स्मार्टफोन डीफॉल्टनुसार यादृच्छिक (randomised) MAC पत्ते वापरतात, ज्यामुळे MAB पूर्णपणे निकामी होते, आणि MAC पत्ते काही सेकंदात स्पूफ केले जाऊ शकतात. आधुनिक नेटवर्क आर्किटेक्चरसाठी EAP-TLS वापरून 802.1X ऑथेंटिकेशन आवश्यक आहे. हे सुनिश्चित करते की प्रत्येक डिव्हाइस नेटवर्कला स्पर्श करण्यापूर्वी क्रिप्टोग्राफिकली सत्यापित केले जाते. परंतु आव्हान हे आहे: तुमच्या हेल्पडेस्कवर ताण न आणता हजारो अनमॅनेज्ड डिव्हाइसेसना युनिक क्लायंट सर्टिफिकेट्स कसे वितरित करायचे? याचे उत्तर आहे सिम्पल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल किंवा SCEP. चला आर्किटेक्चरपासून सुरुवात करूया. SCEP हे एंटरप्राइझ डिव्हाइस एनरोलमेंटसाठीचे उद्योग मानक आहे, जे RFC 8894 मध्ये परिभाषित केले आहे. हे १९९९ पासून अस्तित्वात आहे, मूळतः VeriSign द्वारे तयार केले गेले आहे, आणि ते काळाच्या कसोटीवर टिकले आहे कारण ते खरोखर कठीण समस्येचे उत्कृष्टपणे निराकरण करते. SCEP वर्कफ्लोमध्ये, डिव्हाइस स्थानिक पातळीवर स्वतःची प्रायव्हेट आणि पब्लिक की पेअर जनरेट करते. हे एक सर्टिफिकेट सायनिंग रिक्वेस्ट किंवा CSR तयार करते आणि नेटवर्क डिव्हाइस एनरोलमेंट सर्व्हिस म्हणजेच NDES द्वारे तुमच्या सर्टिफिकेट अथॉरिटी किंवा CA कडे पाठवते. CA विनंती प्रमाणित करतो आणि स्वाक्षरी केलेले पब्लिक सर्टिफिकेट डिव्हाइसला परत करतो. येथे महत्त्वाचा सुरक्षा फायदा असा आहे की प्रायव्हेट की कधीही डिव्हाइस सोडत नाही. हे स्थानिक पातळीवर जनरेट केले जाते आणि डिव्हाइसच्या हार्डवेअर सिक्युर एन्क्लेव्हमध्ये स्टोअर केले जाते. विंडोज लॅपटॉपवर, ते Trusted Platform Module किंवा TPM असते. आयफोनवर, ते Secure Enclave असते. प्रायव्हेट की कधीही नेटवर्कवर ट्रान्समिट केली जात नाही. हेच SCEP ला नेटवर्क ऑथेंटिकेशनसाठी PKCS सारख्या पर्यायांपेक्षा अत्यंत श्रेष्ठ बनवते, जेथे CA मध्यवर्ती पातळीवर की पेअर जनरेट करतो आणि डिव्हाइसवर ट्रान्समिट करतो. आता, BYOD बद्दल बोलूया. ऑपरेशनल दृष्टिकोनातून हे खरोखर मनोरंजक आहे. तुम्हाला कर्मचाऱ्यांना अंतर्गत टूल्स वापरण्यासाठी त्यांचे वैयक्तिक डिव्हाइसेस वापरण्याची परवानगी द्यायची आहे, परंतु तुम्हाला त्यांना तुमच्या कॉर्पोरेट MDM मध्ये एनरोल करण्यास भाग पाडायचे नाही. ही गोपनीयतेची चिंता आहे आणि कर्मचाऱ्यांकडून याला तीव्र विरोध होतो. याचे समाधान म्हणजे सेल्फ-सर्व्हिस ऑनबोर्डिंग पोर्टल. हे कसे कार्य करते ते येथे आहे. युझर त्यांचे वैयक्तिक डिव्हाइस एका समर्पित प्रोव्हिजनिंग SSID शी कनेक्ट करतो. हे नेटवर्क एक मर्यादित क्षेत्र (walled garden) आहे, जे ऑनबोर्डिंग पोर्टल आणि तुमच्या आयडेंटिटी प्रोव्हाइडरशिवाय इतर कशाचाही ॲक्सेस प्रतिबंधित करते. युझर त्याच्या कॉर्पोरेट क्रेडेंशियल्सचा वापर करून ऑथेंटिकेट करतो, सामान्यतः Microsoft Entra ID, Okta किंवा Google Workspace सह SAML इंटिग्रेशनद्वारे. यशस्वी ऑथेंटिकेशन झाल्यावर, सिस्टम SCEP द्वारे एक युनिक, डिव्हाइस-विशिष्ट क्लायंट सर्टिफिकेट जनरेट करते. सर्टिफिकेट, रूट CA सर्टिफिकेट आणि नेटवर्क सेटिंग्ज असलेले कॉन्फिगरेशन प्रोफाइल डिव्हाइसवर पुश केले जाते. त्यानंतर डिव्हाइस EAP-TLS वापरून सुरक्षित कॉर्पोरेट SSID शी स्वयंचलितपणे कनेक्ट होते. हे युझरसाठी अखंड आणि एंटरप्राइझसाठी सुरक्षित आहे. त्यांना सर्टिफिकेट्स किंवा 802.1X बद्दल काहीही माहित असण्याची गरज नाही. ते फक्त एकदा लॉग इन करतात आणि कनेक्ट होतात. आता, अंमलबजावणीचा सविस्तर आढावा घेऊया. डिप्लॉयमेंटचा क्रम अत्यंत महत्त्वाचा आहे आणि तो चुकीचा होणे हे अपयशाचे सर्वात सामान्य कारण आहे. पहिली पायरी: Trusted Root सर्टिफिकेट डिप्लॉय करा. कोणतेही डिव्हाइस क्लायंट सर्टिफिकेटची विनंती करण्यापूर्वी किंवा तुमच्या RADIUS सर्व्हरवर विश्वास ठेवण्यापूर्वी, त्याने जारी करणाऱ्या सर्टिफिकेट अथॉरिटीवर विश्वास ठेवला पाहिजे. तुमचे Root CA सर्टिफिकेट .cer फाइल म्हणून एक्सपोर्ट करा आणि ते तुमच्या लक्ष्यित डिव्हाइस ग्रुप्सवर डिप्लॉय करा. ही पायरी बंधनकारक आहे. याशिवाय, संपूर्ण साखळी अयशस्वी होते. दुसरी पायरी: SCEP सर्टिफिकेट प्रोफाइल कॉन्फिगर करा. हे डिव्हाइसेसना त्यांचे क्लायंट सर्टिफिकेट कसे मिळवायचे याबद्दल सूचना देते. तुम्हाला सब्जेक्ट नेम फॉरमॅट कॉन्फिगर करणे आवश्यक आहे. युझर-चालित ऑथेंटिकेशनसाठी, मानक CN equals UserPrincipalName आहे. डिव्हाइस ऑथेंटिकेशनसाठी, CN equals Azure AD Device ID वापरा. की युसेज डिजिटल सिग्नेचर आणि की एनसायफरमेंटवर सेट करा. एक्सटेंडेड की युसेज अंतर्गत, OID 1.3.6.1.5.5.7.3.2 सह Client Authentication निर्दिष्ट करा. या प्रोफाइलला पहिल्या पायरीवरील Trusted Root सर्टिफिकेट प्रोफाइलशी लिंक करा. आणि तुमच्या NDES सर्व्हरचा बाह्य URL प्रदान करा. तिसरी पायरी: 802.1X WiFi प्रोफाइल डिप्लॉय करा. हे सर्टिफिकेट्सना नेटवर्क SSID शी जोडते. तुमच्या ॲक्सेस पॉइंट्सद्वारे ब्रॉडकास्ट केल्याप्रमाणे नेटवर्कचे नाव अचूक प्रविष्ट करा. सुरक्षा प्रकार WPA2-Enterprise किंवा WPA3-Enterprise वर सेट करा. EAP प्रकार EAP-TLS वर सेट करा. क्लायंट ऑथेंटिकेशन सर्टिफिकेट म्हणून SCEP सर्टिफिकेट प्रोफाइल निवडा. आणि सर्व्हर व्हॅलिडेशनसाठी Trusted Root सर्टिफिकेट निर्दिष्ट करा. या संपूर्ण ब्रीफिंगमधून लक्षात ठेवण्याची ही सर्वात महत्त्वाची गोष्ट आहे. विश्वास (Trust), नंतर सर्टिफिकेट, नंतर WiFi. याच क्रमाने, प्रत्येक वेळी. आता मी तुम्हाला काही सर्वोत्तम पद्धती सांगतो ज्या तुम्हाला उत्पादनादरम्यान मोठ्या त्रासापासून वाचवतील. पहिले, Azure AD Application Proxy द्वारे तुमचा NDES सर्व्हर प्रकाशित करा. रिमोट डिव्हाइसेस ऑन-साइट येण्यापूर्वी त्यांना सर्टिफिकेट्स प्रोव्हिजन करण्याची परवानगी देण्यासाठी NDES सर्व्हर इंटरनेटवरून ॲक्सेस करण्यायोग्य असणे आवश्यक आहे. परंतु अंतर्गत सर्व्हर थेट इंटरनेटवर उघड करणे हा एक मोठा सुरक्षा धोका आहे. Application Proxy तुम्हाला इनबाउंड फायरवॉल पोर्ट्स न उघडता सुरक्षित रिमोट ॲक्सेस देते. दुसरे, BYOD डिव्हाइसेससाठी अल्पायुषी सर्टिफिकेट्स लागू करा. तीन वर्षांसाठी वैध असलेल्या सर्टिफिकेटऐवजी, ९० दिवसांसाठी वैध असलेली सर्टिफिकेट्स जारी करा. जेव्हा सर्टिफिकेट कालबाह्य होते, तेव्हा युझरने ऑनबोर्डिंग पोर्टलद्वारे पुन्हा ऑथेंटिकेट करणे आवश्यक आहे. हे नैसर्गिकरित्या नेटवर्कमधून जुनी डिव्हाइसेस काढून टाकते. ९० दिवसांत न वापरलेले डिव्हाइस सहजपणे बाहेर पडते. कोणत्याही मॅन्युअल क्लीनअपची आवश्यकता नाही. तिसरे, आणि हे अत्यंत गंभीर आहे, तुमच्या RADIUS सर्व्हरला कठोर सर्टिफिकेट रिव्होकेशन लिस्ट (CRL) चेकिंग लागू करण्यासाठी कॉन्फिगर करा. जेव्हा एखादा कर्मचारी संस्था सोडतो, तेव्हा त्याचे Active Directory खाते निष्क्रिय केल्याने त्याचे क्लायंट सर्टिफिकेट वैध असल्यास त्याचा WiFi ॲक्सेस त्वरित रद्द होणार नाही. तुमच्या RADIUS सर्व्हरने ॲक्सेस देण्यापूर्वी CRL तपासले पाहिजे. तुमचे CRL डिस्ट्रिब्युशन पॉइंट्स अत्यंत उपलब्ध असल्याची खात्री करा. जर RADIUS सर्व्हर CRL पर्यंत पोहोचू शकला नाही, तर सर्वांसाठी ऑथेंटिकेशन अयशस्वी होते. तो एक मोठा आउटेज ठरेल. आता आपण काही सामान्य अपयशाचे प्रकार आणि ते कसे टाळायचे ते पाहूया. सर्वात वारंवार येणारी समस्या म्हणजे WiFi प्रोफाइल लागू न होणे. डिव्हाइसला Trusted Root आणि SCEP सर्टिफिकेट्स मिळतात, परंतु WiFi प्रोफाइल MDM कन्सोलमध्ये Error म्हणून दर्शवते. दहापैकी नऊ वेळा, ही ग्रुप टार्गेटिंग विसंगती असते. जर SCEP प्रोफाइल युझर ग्रुपला नियुक्त केले असेल, परंतु WiFi प्रोफाइल डिव्हाइस ग्रुपला नियुक्त केले असेल, तर MDM डिपेंडन्सी सोडवू शकत नाही. तुमच्या असाइनमेंट्सचे ऑडिट करा. तिन्ही प्रोफाइल्स एकाच ग्रुपला लक्ष्य करत असल्याची खात्री करा. दुसरी सामान्य समस्या म्हणजे NDES 403 Forbidden एरर. डिव्हाइसेस SCEP सर्टिफिकेट मिळवण्यात अपयशी ठरतात आणि NDES IIS लॉग HTTP 403 एरर दर्शवतात. हे सहसा सर्टिफिकेट टेम्पलेटवर कनेक्टर सर्व्हिस अकाउंटमध्ये आवश्यक परवानग्या नसल्यामुळे किंवा फायरवॉल SCEP द्वारे वापरल्या जाणाऱ्या विशिष्ट क्वेरी स्ट्रिंग पॅरामीटर्सना ब्लॉक करत असल्यामुळे होते. कनेक्टर अकाउंटमध्ये CA टेम्पलेटवर Read आणि Enroll परवानग्या असल्याची पडताळणी करा. operation equals GetCACaps पॅरामीटर असलेल्या URL ब्लॉक केल्या जात नाहीत याची खात्री करण्यासाठी तुमचे फायरवॉल लॉग तपासा. हे व्यवहारात कसे घडते हे स्पष्ट करण्यासाठी मी तुम्हाला दोन वास्तविक परिस्थिती सांगतो. परिस्थिती एक: एका २०० खोल्यांच्या हॉटेलमध्ये ५० हाउसकीपिंग कर्मचारी शेड्यूलिंग ॲप वापरण्यासाठी वैयक्तिक स्मार्टफोन वापरत आहेत. IT मॅनेजरला कर्मचाऱ्यांच्या गोपनीयतेचा आदर करण्यासाठी पूर्ण MDM एनरोलमेंट टाळायची आहे. याचे समाधान म्हणजे Microsoft Entra ID सह एकत्रित केलेले सेल्फ-सर्व्हिस पोर्टल. कर्मचारी प्रोव्हिजनिंग SSID शी कनेक्ट होतात, त्यांच्या Entra ID क्रेडेंशियल्ससह लॉग इन करतात आणि SCEP प्रोफाइल डाउनलोड करतात. SCEP सर्व्हर थेट डिव्हाइसवर ३० दिवसांचे क्लायंट सर्टिफिकेट जारी करतो. डिव्हाइस EAP-TLS वापरून Staff WiFi SSID शी कनेक्ट होते. RADIUS सर्व्हर या डिव्हाइसेसना एका प्रतिबंधित VLAN मध्ये नियुक्त करतो जो केवळ शेड्यूलिंग ॲपला ॲक्सेस देतो. जेव्हा एखादा कर्मचारी राजीनामा देतो, तेव्हा त्याचे Entra ID खाते निष्क्रिय केले जाते आणि RADIUS सर्व्हर त्वरित नेटवर्क ॲक्सेस नाकारतो. परिस्थिती दोन: ५०० स्टोअर्स असलेली एक राष्ट्रीय रिटेल चेन कॉर्पोरेट-मालकीच्या पॉइंट-ऑफ-सेल टॅब्लेटसाठी सुरक्षित WiFi डिप्लॉय करत आहे. नेटवर्क आर्किटेक्टला हे सुनिश्चित करायचे आहे की टॅब्लेट चोरीला गेला तरीही क्रेडेंशियल्स काढले जाऊ शकत नाहीत. याचे समाधान म्हणजे Microsoft Intune SCEP द्वारे सर्टिफिकेट्स डिप्लॉय करणे. Intune Trusted Root सर्टिफिकेट पुश करते, त्यानंतर एक SCEP प्रोफाइल पाठवते जे टॅब्लेटला त्याच्या हार्डवेअर सिक्युर एन्क्लेव्हमध्ये स्वतःची प्रायव्हेट की जनरेट करण्याची सूचना देते. टॅब्लेट NDES सर्व्हरला CSR सबमिट करतो, क्लायंट सर्टिफिकेट प्राप्त करतो आणि EAP-TLS वापरून Retail POS SSID शी कनेक्ट होतो. प्रायव्हेट की स्थानिक पातळीवर जनरेट केली जात असल्याने आणि कधीही ट्रान्समिट केली जात नसल्याने, चोरी झालेल्या टॅब्लेटचे क्रेडेंशियल्स इतरत्र वापरले जाऊ शकत नाहीत. हे PCI DSS अनुपालन आवश्यकता पूर्ण करते. आता, बिझनेस केसबद्दल बोलूया. SCEP 802.1X सर्टिफिकेट डिप्लॉयमेंटवर जाणे सुरक्षा आणि ऑपरेशन्समध्ये मोजता येण्याजोगा परतावा देते. पासवर्ड-आधारित WiFi मोठ्या प्रमाणावर हेल्पडेस्क तिकिटे जनरेट करते. पासवर्ड समाप्ती, लॉकआउट्स, टायपिंगच्या चुका. सर्टिफिकेट-आधारित ऑथेंटिकेशन युझरसाठी अदृश्य असते. डिव्हाइसेस स्वयंचलितपणे कनेक्ट होतात. हे सामान्यतः WiFi-संबंधित हेल्पडेस्क व्हॉल्यूम ७०% ने कमी करते. हा ऑपरेशनल खर्चामध्ये मोठा घट आहे. EAP-TLS क्रेडेंशियल चोरी आणि मॅन-इन-द-मिडल हल्ल्यांचा धोका दूर करते. रिटेल वातावरणात PCI DSS आणि सर्व क्षेत्रांमध्ये GDPR च्या अनुपालनासाठी हे अत्यंत महत्त्वाचे आहे. डेटा ब्रीचचा खर्च योग्य PKI पायाभूत सुविधा डिप्लॉय करण्याच्या खर्चापेक्षा कितीतरी जास्त असतो. आणि आधीच Purple चे Guest WiFi आणि ॲनालिटिक्स प्लॅटफॉर्म वापरत असलेल्या संस्थांसाठी, कर्मचाऱ्यांच्या BYOD डिव्हाइसेसवर सुरक्षित ऑनबोर्डिंगचा विस्तार करणे एक युनिफाइड नेटवर्क मॅनेजमेंट धोरण प्रदान करते. Purple चे हार्डवेअर-अज्ञेयवादी क्लाउड ओव्हरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet सह एकत्रित होते, त्यामुळे तुम्ही एकाच हार्डवेअर व्हेंडरपुरते मर्यादित राहत नाही. Purple ८०,००० हून अधिक थेट वेन्यूमध्ये कार्यरत आहे आणि त्याने २०२४ मध्ये ४४० दशलक्ष लॉगइन्सवर प्रक्रिया केली आहे, ज्याच्याकडे ISO 27001, GDPR, CCPA आणि Cyber Essentials सर्टिफिकेशन्स आहेत. तुम्हाला घ्याव्या लागणाऱ्या महत्त्वाच्या निर्णयांच्या जलद सारांशासह मी समाप्त करतो. तुम्ही SCEP वापरावे की PKCS? WiFi ऑथेंटिकेशनसाठी SCEP वापरा. प्रायव्हेट की डिव्हाइसवरच राहते. केवळ ईमेल एन्क्रिप्शनसाठी PKCS वापरा जेथे की एस्क्रो आवश्यक आहे. सर्टिफिकेट्स किती काळ वैध असावीत? BYOD साठी ९० दिवस. कॉर्पोरेट-मॅनेज्ड डिव्हाइसेससाठी एक ते दोन वर्षे. तुम्ही तुमच्या MDM मध्ये युझर की डिव्हाइस टार्गेटिंग वापरावे? युझर लॉग इन करण्यापूर्वी कनेक्ट होणे आवश्यक असलेल्या कॉर्पोरेट डिव्हाइसेससाठी डिव्हाइस टार्गेटिंग वापरा. BYOD साठी युझर टार्गेटिंग वापरा जेथे सर्टिफिकेट वैयक्तिक व्यक्तीशी जोडलेले असावे. तुम्ही Android फ्रॅगमेंटेशन कसे हाताळता? शक्य तिथे Passpoint, ज्याला Hotspot 2.0 देखील म्हटले जाते, वापरा. हे सर्व Android उत्पादकांमध्ये सुसंगत कनेक्शन अनुभव प्रदान करते. आणि शेवटी, सर्वात महत्त्वाची गोष्ट कोणती आहे? तुमच्या RADIUS सर्व्हरवर CRL चेकिंग. याशिवाय, रद्द केलेले सर्टिफिकेट देखील नेटवर्क ॲक्सेस देऊ शकते. हे आजच्या ब्रीफिंगचे शेवट आहे. जर तुम्हाला यापैकी कोणत्याही विषयावर सखोल माहिती हवी असेल, तर एंटरप्राइझ WiFi सुरक्षा आणि EAP-TLS सर्टिफिकेट ऑथेंटिकेशनवरील Purple चे तांत्रिक मार्गदर्शक Purple च्या purple.ai या वेबसाइटवर उपलब्ध आहेत. ऐकल्याबद्दल धन्यवाद.