सुरक्षित Enterprise WiFi आणि BYOD प्रोव्हिजनिंगसाठी SCEP कसे कॉन्फिगर करावे

Purple कडून या तांत्रिक ब्रीफिंगमध्ये आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण सुरक्षित एंटरप्राइझ WiFi आणि BYOD प्रोव्हिजनिंगसाठी SCEP च्या कॉन्फिगरेशनचा सखोल अभ्यास करत आहोत. हॉस्पिटॅलिटी, रिटेल आणि सार्वजनिक क्षेत्रांमध्ये कार्यरत असलेल्या IT मॅनेजर्स, नेटवर्क आर्किटेक्ट्स आणि CTOs साठी, नेटवर्क ॲक्सेस व्यवस्थापित करणे हे सुरक्षा आणि ऑपरेशनल कार्यक्षमता यामधील एक सततचे संतुलन राखण्याचे काम आहे. तुम्ही दररोज तुमच्या नेटवर्कशी कनेक्ट होणाऱ्या शेकडो, कधीकधी हजारो डिव्हाइसेस हाताळत आहात. कर्मचाऱ्यांचे स्मार्टफोन, कंत्राटदारांचे लॅपटॉप, पॉइंट-ऑफ-सेल टॅब्लेट. आणि हे हाताळण्याचे जुने मार्ग आता पुरेसे राहिलेले नाहीत. कर्मचारी आणि BYOD WiFi साठी प्री-शेअर्ड की (PSKs) वर अवलंबून राहणे ही एक सुरक्षेची त्रुटी आहे जी कधीही धोक्यात आणू शकते. एकदा का शेअर्ड पासवर्ड लीक झाला की, कोणालाही तुमच्या नेटवर्कमध्ये प्रवेश मिळतो. आणि MAC Authentication Bypass, किंवा MAB, देखील यापेक्षा चांगले नाही. आधुनिक स्मार्टफोन डीफॉल्टनुसार रँडमाइज्ड MAC ॲड्रेस वापरतात, ज्यामुळे MAB पूर्णपणे निकामी होते, आणि MAC ॲड्रेस काही सेकंदात स्पूफ केले जाऊ शकतात. आधुनिक नेटवर्क आर्किटेक्चर EAP-TLS वापरून 802.1X ऑथेंटिकेशनची मागणी करते. हे सुनिश्चित करते की प्रत्येक डिव्हाइस नेटवर्कला स्पर्श करण्यापूर्वी क्रिप्टोग्राफिकली सत्यापित केले गेले आहे. परंतु येथे आव्हान आहे: तुमच्या हेल्पडेस्कवर ताण न आणता तुम्ही हजारो अनमॅनेज्ड डिव्हाइसेसना युनिक क्लायंट सर्टिफिकेट्स कसे वितरित करता? याचे उत्तर आहे Simple Certificate Enrollment Protocol, किंवा SCEP. चला आर्किटेक्चरपासून सुरुवात करूया. SCEP हे एंटरप्राइझ डिव्हाइस एनरोलमेंटसाठीचे इंडस्ट्री स्टँडर्ड आहे, जे RFC 8894 मध्ये परिभाषित केले आहे. हे १९९९ पासून अस्तित्वात आहे, मूळतः VeriSign द्वारे तयार केले गेले आहे, आणि ते काळाच्या कसोटीवर टिकून राहिले आहे कारण ते एका खरोखर कठीण समस्येचे उत्कृष्टपणे निराकरण करते. SCEP वर्कफ्लोमध्ये, डिव्हाइस स्थानिक पातळीवर स्वतःची खाजगी आणि सार्वजनिक की पेअर (key pair) तयार करते. हे एक Certificate Signing Request, किंवा CSR तयार करते आणि ते Network Device Enrollment Service, म्हणजेच NDES द्वारे तुमच्या Certificate Authority, किंवा CA कडे पाठवते. CA विनंतीचे प्रमाणीकरण करते आणि स्वाक्षरी केलेले सार्वजनिक सर्टिफिकेट डिव्हाइसला परत करते. येथे महत्त्वाचा सुरक्षेचा फायदा असा आहे की खाजगी की (private key) कधीही डिव्हाइस सोडत नाही. ती स्थानिक पातळीवर तयार केली जाते आणि डिव्हाइसच्या हार्डवेअर सिक्युर एन्क्लेव्हमध्ये साठवली जाते. Windows लॅपटॉपवर, ते Trusted Platform Module, किंवा TPM असते. iPhone वर, ते Secure Enclave असते. खाजगी की कधीही नेटवर्कवर ट्रान्समिट केली जात नाही. यामुळेच नेटवर्क ऑथेंटिकेशनसाठी PKCS सारख्या पर्यायांपेक्षा SCEP अत्यंत सरस ठरते, जिथे CA मध्यवर्ती पातळीवर की पेअर तयार करते आणि ती डिव्हाइसवर ट्रान्समिट करते. आता, आपण BYOD बद्दल बोलूया. ऑपरेशनल दृष्टिकोनातून हे खरोखरच मनोरंजक बनते. तुम्हाला कर्मचाऱ्यांनी अंतर्गत साधनांमध्ये प्रवेश करण्यासाठी त्यांचे वैयक्तिक डिव्हाइसेस वापरण्यास सक्षम असावे असे वाटते, परंतु तुम्हाला त्यांना तुमच्या कॉर्पोरेट MDM मध्ये एनरोल करण्याची सक्ती करायची नसते. ती गोपनीयतेची चिंता आहे, आणि त्याला कर्मचाऱ्यांकडून तीव्र विरोध होतो. याचे उत्तर म्हणजे सेल्फ-सर्व्हिस ऑनबोर्डिंग पोर्टल. हे कसे कार्य करते ते येथे दिले आहे. युझर त्यांचे वैयक्तिक डिव्हाइस एका समर्पित प्रोव्हिजनिंग SSID शी कनेक्ट करतात. हे नेटवर्क एक वॉल गार्डन (मर्यादित नेटवर्क) असते, जे ऑनबोर्डिंग पोर्टल आणि तुमच्या आयडेंटिटी प्रोव्हाइडर व्यतिरिक्त इतर सर्व गोष्टींचा ॲक्सेस प्रतिबंधित करते. युझर त्यांच्या कॉर्पोरेट क्रेडेंशियल्सचा वापर करून ऑथेंटिकेट करतात, सामान्यतः Microsoft Entra ID, Okta, किंवा Google Workspace सोबतच्या SAML इंटिग्रेशनद्वारे. यशस्वी ऑथेंटिकेशन झाल्यावर, सिस्टम SCEP द्वारे एक युनिक, डिव्हाइस-विशिष्ट क्लायंट सर्टिफिकेट जनरेट करते. डिव्हाइसवर एक कॉन्फिगरेशन प्रोफाइल पाठवले जाते ज्यामध्ये सर्टिफिकेट, रूट CA सर्टिफिकेट आणि नेटवर्क सेटिंग्स असतात. त्यानंतर डिव्हाइस EAP-TLS चा वापर करून सुरक्षित कॉर्पोरेट SSID शी आपोआप कनेक्ट होते. हे युझरसाठी अत्यंत सोपे आणि एंटरप्राइझसाठी सुरक्षित आहे. त्यांना सर्टिफिकेट्स किंवा 802.1X बद्दल काहीही माहिती असण्याची गरज नाही. ते फक्त एकदा लॉग इन करतात आणि कनेक्ट होतात. आता, आपण याच्या अंमलबजावणीची सविस्तर माहिती घेऊया. डिप्लॉयमेंटचा क्रम अत्यंत महत्त्वाचा आहे, आणि यामध्ये चूक होणे हे अपयशाचे सर्वात सामान्य कारण आहे. पहिले पाऊल: ट्रस्टेड रूट सर्टिफिकेट (Trusted Root Certificate) डिप्लॉय करा. कोणतेही डिव्हाइस क्लायंट सर्टिफिकेटची विनंती करण्यापूर्वी किंवा तुमच्या RADIUS सर्व्हरवर विश्वास ठेवण्यापूर्वी, त्याने जारी करणाऱ्या सर्टिफिकेट ऑथॉरिटीवर विश्वास ठेवला पाहिजे. तुमचे Root CA सर्टिफिकेट .cer फाईल म्हणून एक्सपोर्ट करा आणि ते तुमच्या लक्ष्यित डिव्हाइस ग्रुप्सवर डिप्लॉय करा. हे पाऊल अनिवार्य आहे. याशिवाय, संपूर्ण साखळी अयशस्वी ठरते. दुसरे पाऊल: SCEP सर्टिफिकेट प्रोफाइल कॉन्फिगर करा. हे डिव्हाइसेसना त्यांचे क्लायंट सर्टिफिकेट कसे मिळवायचे याचे निर्देश देते. तुम्हाला सब्जेक्ट नेम फॉरमॅट कॉन्फिगर करणे आवश्यक आहे. युझर-चालित ऑथेंटिकेशनसाठी, CN म्हणजे UserPrincipalName हा स्टँडर्ड आहे. डिव्हाइस ऑथेंटिकेशनसाठी, CN म्हणजे Azure AD Device ID वापरा. की युसेज (key usage) डिजिटल सिग्नेचर आणि की एन्सायफरमेंटवर सेट करा. एक्सटेंडेड की युसेज अंतर्गत, OID 1.3.6.1.5.5.7.3.2 सह क्लायंट ऑथेंटिकेशन निर्दिष्ट करा. हे प्रोफाइल पहिल्या पाऊलातील ट्रस्टेड रूट सर्टिफिकेट प्रोफाइलशी लिंक करा. आणि तुमच्या NDES सर्व्हरची एक्सटर्नल URL प्रदान करा. तिसरे पाऊल: 802.1X WiFi प्रोफाइल डिप्लॉय करा. हे सर्टिफिकेट्सना नेटवर्क SSID शी जोडते. तुमच्या ॲक्सेस पॉईंट्सद्वारे ब्रॉडकास्ट केले जाणारे नेटवर्कचे नाव जसेच्या तसे प्रविष्ट करा. सिक्युरिटी टाईप WPA2-Enterprise किंवा WPA3-Enterprise वर सेट करा. EAP टाईप EAP-TLS वर सेट करा. क्लायंट ऑथेंटिकेशन सर्टिफिकेट म्हणून SCEP सर्टिफिकेट प्रोफाइल निवडा. आणि सर्व्हर व्हॅलिडेशनसाठी ट्रस्टेड रूट सर्टिफिकेट निर्दिष्ट करा. या संपूर्ण माहितीमधून लक्षात ठेवण्याची सर्वात महत्त्वाची गोष्ट म्हणजे हा क्रम होय. आधी ट्रस्ट, नंतर सर्टिफिकेट, आणि मग WiFi. याच क्रमाने, प्रत्येक वेळी. आता मी तुम्हाला काही सर्वोत्तम पद्धती सांगतो ज्या तुम्हाला प्रत्यक्ष वापरात येणाऱ्या मोठ्या त्रासापासून वाचवतील. पहिले म्हणजे, तुमचे NDES सर्व्हर Azure AD Application Proxy द्वारे पब्लिश करा. रिमोट डिव्हाइसेसना प्रत्यक्ष ठिकाणी येण्यापूर्वी सर्टिफिकेट्स प्रोव्हिजन करण्याची परवानगी देण्यासाठी NDES सर्व्हर इंटरनेटवरून ॲक्सेस करण्यायोग्य असणे आवश्यक आहे. परंतु अंतर्गत सर्व्हर थेट इंटरनेटवर उघड करणे हा एक मोठा सुरक्षा धोका आहे. Application Proxy तुम्हाला इनबाउंड फायरवॉल पोर्ट्स न उघडता सुरक्षित रिमोट ॲक्सेस प्रदान करते. दुसरे म्हणजे, BYOD उपकरणांसाठी कमी कालावधीची प्रमाणपत्रे (short-lived certificates) लागू करा. तीन वर्षांसाठी वैध असलेल्या प्रमाणपत्राऐवजी, ९० दिवसांसाठी वैध असलेली प्रमाणपत्रे जारी करा. जेव्हा प्रमाणपत्र कालबाह्य होईल, तेव्हा वापरकर्त्याला ऑनबोर्डिंग पोर्टलद्वारे पुन्हा प्रमाणीकरण करावे लागेल. यामुळे नेटवर्कवरील वापरात नसलेली जुनी उपकरणे आपोआप काढून टाकली जातात. ९० दिवसांत न वापरलेले उपकरण सहजपणे नेटवर्कवरून बाहेर पडते. कोणत्याही मॅन्युअल क्लीनअपची आवश्यकता नसते. तिसरे, आणि हे अत्यंत महत्त्वाचे आहे, तुमच्या RADIUS सर्व्हरला कठोर Certificate Revocation List (CRL) तपासणी लागू करण्यासाठी कॉन्फिगर करा. जेव्हा एखादा कर्मचारी संस्था सोडतो, तेव्हा त्यांचे Active Directory खाते निष्क्रिय केल्याने त्यांचा WiFi प्रवेश त्वरित रद्द होणार नाही जर त्यांचे क्लायंट प्रमाणपत्र वैध राहिले असेल. प्रवेश मंजूर करण्यापूर्वी तुमच्या RADIUS सर्व्हरने CRL तपासणे आवश्यक आहे. तुमचे CRL Distribution Points अत्यंत उपलब्ध (highly available) असल्याची खात्री करा. जर RADIUS सर्व्हर CRL पर्यंत पोहोचू शकला नाही, तर प्रत्येकासाठी प्रमाणीकरण अपयशी ठरते. हा एक मोठा आउटेज असू शकतो. आता आपण काही सामान्य बिघाड प्रकार (failure modes) आणि ते कसे टाळायचे ते पाहूया. सर्वात वारंवार येणारी समस्या म्हणजे WiFi प्रोफाइल लागू न होणे. उपकरणाला Trusted Root आणि SCEP प्रमाणपत्रे मिळतात, परंतु MDM कन्सोलमध्ये WiFi प्रोफाइल 'Error' म्हणून दर्शवते. दहापैकी नऊ वेळा, हे ग्रुप टार्गेटिंगमधील विसंगतीमुळे होते. जर SCEP प्रोफाइल User Group ला नियुक्त केले असेल, परंतु WiFi प्रोफाइल Device Group ला नियुक्त केले असेल, तर MDM या अवलंबित्वाची (dependency) सोडवणूक करू शकत नाही. तुमच्या नियुक्त्यांचे ऑडिट करा. तिन्ही प्रोफाइल एकाच ग्रुपला टार्गेट करत असल्याची खात्री करा. दुसरी सामान्य समस्या म्हणजे NDES 403 Forbidden त्रुटी. उपकरणे SCEP प्रमाणपत्र मिळवण्यात अपयशी ठरतात आणि NDES IIS लॉग्समध्ये HTTP 403 त्रुटी दिसतात. हे सहसा कनेक्टर सर्व्हिस खात्याकडे प्रमाणपत्र टेम्पलेटवर आवश्यक परवानग्या नसल्यामुळे किंवा SCEP द्वारे वापरल्या जाणाऱ्या विशिष्ट क्वेरी स्ट्रिंग पॅरामीटर्सना फायरवॉल ब्लॉक करत असल्यामुळे होते. कनेक्टर खात्याकडे CA टेम्पलेटवर Read आणि Enroll परवानग्या असल्याची पडताळणी करा. 'operation equals GetCACaps' पॅरामीटर असलेल्या URLs ब्लॉक केल्या जात नाहीत याची खात्री करण्यासाठी तुमचे फायरवॉल लॉग्स तपासा. हे प्रत्यक्ष व्यवहारात कसे कार्य करते हे स्पष्ट करण्यासाठी मी तुम्हाला दोन वास्तविक परिस्थितींची उदाहरणे देतो. परिस्थिती एक: २०० खोल्यांचे हॉटेल ज्यामध्ये ५० हाउसकीपिंग कर्मचारी शेड्यूलिंग ॲप वापरण्यासाठी वैयक्तिक स्मार्टफोन वापरतात. कर्मचाऱ्यांच्या गोपनीयतेचा आदर करण्यासाठी 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 प्रोफाइल टॅब्लेटला त्याच्या हार्डवेअर सुरक्षित एन्क्लेव्हमध्ये स्वतःची खाजगी की (private key) तयार करण्याचे निर्देश देते. टॅब्लेट NDES सर्व्हरकडे CSR सबमिट करतो, क्लायंट प्रमाणपत्र प्राप्त करतो आणि EAP-TLS चा वापर करून Retail POS SSID शी कनेक्ट होतो. खाजगी की स्थानिक पातळीवर तयार केली जात असल्याने आणि ती कधीही प्रसारित केली जात नसल्यामुळे, चोरी झालेल्या टॅब्लेटचे क्रेडेंशियल्स इतर कोठेही वापरले जाऊ शकत नाहीत. हे PCI DSS अनुपालन आवश्यकता पूर्ण करते. आता, आपण बिझनेस केसबद्दल बोलूया. SCEP 802.1X प्रमाणपत्र तैनातीकडे संक्रमण केल्याने सुरक्षा आणि ऑपरेशन्समध्ये मोजता येण्याजोगा परतावा मिळतो. पासवर्ड-आधारित WiFi मुळे हेल्पडेस्क तिकिटांची मोठी संख्या निर्माण होते. पासवर्डची मुदत संपणे, लॉकआउट्स, टायपिंगच्या चुका. प्रमाणपत्र-आधारित प्रमाणीकरण वापरकर्त्यासाठी अदृश्य असते. डिव्हाइसेस आपोआप कनेक्ट होतात. यामुळे सामान्यतः WiFi-संबंधित हेल्पडेस्कचे प्रमाण ७०% ने कमी होते. हा ऑपरेशनल खर्चामध्ये झालेला एक महत्त्वपूर्ण घट आहे. EAP-TLS क्रेडेंशियल हार्वेस्टिंग आणि मॅन-इन-द-मिडल (Man-in-the-Middle) हल्ल्यांचा धोका काढून टाकते. रिटेल वातावरणात PCI DSS आणि सर्व क्षेत्रांमध्ये GDPR च्या अनुपालनासाठी हे अत्यंत महत्त्वाचे आहे. डेटा लीकचा खर्च योग्य PKI इन्फ्रास्ट्रक्चर तैनात करण्याच्या खर्चापेक्षा कितीतरी पटीने जास्त असतो. आणि जे उद्योग आधीच Purple चे Guest WiFi आणि ॲनालिटिक्स प्लॅटफॉर्म चालवत आहेत, त्यांच्यासाठी कर्मचाऱ्यांच्या BYOD डिव्हाइसेसवर सुरक्षित ऑनबोर्डिंगचा विस्तार करणे एक युनिफाइड नेटवर्क मॅनेजमेंट स्ट्रॅटेजी प्रदान करते. Purple चे हार्डवेअर-अज्ञेयवादी (hardware-agnostic) क्लाउड ओव्हरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet सोबत समाकलित होते, त्यामुळे तुम्ही एकाच हार्डवेअर विक्रेत्यापुरते मर्यादित राहत नाही. Purple ८०,००० हून अधिक थेट ठिकाणांवर कार्यरत आहे आणि २०२४ मध्ये ४४० दशलक्ष लॉगिन प्रक्रियेतून गेले आहेत, तसेच त्यांच्याकडे ISO 27001, GDPR, CCPA आणि Cyber Essentials प्रमाणपत्रे आहेत. तुम्हाला घ्याव्या लागणाऱ्या मुख्य निर्णयांच्या जलद सारांशासह मी समारोप करतो. तुम्ही SCEP वापरावे की PKCS? WiFi प्रमाणीकरणासाठी SCEP वापरा. खाजगी की डिव्हाइसवरच राहते. PKCS चा वापर केवळ ईमेल एन्क्रिप्शनसाठी करा जिथे की एस्क्रो (key escrow) आवश्यक आहे. प्रमाणपत्रे किती काळ वैध असावीत? BYOD साठी ९० दिवस. कॉर्पोरेट-व्यवस्थापित डिव्हाइसेससाठी एक ते दोन वर्षे. तुम्ही तुमच्या MDM मध्ये वापरकर्ता (user) की डिव्हाइस (device) लक्ष्यीकरण वापरावे? वापरकर्ता लॉगिन करण्यापूर्वी कनेक्ट करणे आवश्यक असलेल्या कॉर्पोरेट डिव्हाइसेससाठी डिव्हाइस लक्ष्यीकरण वापरा. BYOD साठी वापरकर्ता लक्ष्यीकरण वापरा जिथे प्रमाणपत्र वैयक्तिक व्यक्तीशी जोडलेले असावे. तुम्ही Android फ्रॅगमेंटेशन कसे हाताळता? शक्य तिथे Passpoint वापरा, ज्याला Hotspot 2.0 देखील म्हटले जाते. हे Android उत्पादकांमध्ये एक सुसंगत कनेक्शन अनुभव प्रदान करते. आणि शेवटी, कोणती एक गोष्ट अचूक असणे सर्वात महत्त्वाचे आहे? तुमच्या RADIUS सर्व्हरवर CRL चेकिंग. त्याशिवाय, रद्द केलेले प्रमाणपत्र देखील नेटवर्क प्रवेश मंजूर करू शकते. आजची माहिती इथेच संपत आहे. जर तुम्हाला यापैकी कोणत्याही विषयावर अधिक सखोल माहिती हवी असेल, तर Purple चे एंटरप्राइझ WiFi सुरक्षा आणि EAP-TLS प्रमाणपत्र प्रमाणीकरणावरील तांत्रिक मार्गदर्शक Purple च्या वेबसाइटवर purple.ai येथे उपलब्ध आहेत. ऐकल्याबद्दल धन्यवाद.