सुरक्षित एंटरप्राइज WiFi और BYOD प्रोविजनिंग के लिए SCEP को कैसे कॉन्फ़िगर करें

Purple के इस तकनीकी ब्रीफिंग में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम सुरक्षित एंटरप्राइज WiFi और BYOD प्रोविजनिंग के लिए SCEP के कॉन्फ़िगरेशन का गहन विश्लेषण कर रहे हैं। हॉस्पिटैलिटी, रिटेल और सार्वजनिक क्षेत्रों में काम करने वाले IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और CTOs के लिए, नेटवर्क एक्सेस को प्रबंधित करना सुरक्षा और परिचालन दक्षता के बीच एक निरंतर संतुलन बनाने जैसा है। आप हर दिन अपने नेटवर्क से जुड़ने वाले सैकड़ों, कभी-कभी हजारों डिवाइसेस से निपट रहे हैं। कर्मचारियों के स्मार्टफोन, ठेकेदारों के लैपटॉप, पॉइंट-ऑफ-सेल टैबलेट। और इसे संभालने के पुराने तरीके अब बिल्कुल भी पर्याप्त नहीं हैं। कर्मचारियों और BYOD WiFi के लिए प्री-शेयर्ड कीज़, या PSKs पर भरोसा करना एक सुरक्षा भेद्यता (vulnerability) है जिसका फायदा उठाया जा सकता है। एक बार साझा पासवर्ड से समझौता हो जाने पर, यह किसी को भी आपके नेटवर्क तक पहुंच प्रदान कर देता है। और MAC Authentication Bypass, या MAB, भी इससे बेहतर नहीं है। आधुनिक स्मार्टफोन डिफ़ॉल्ट रूप से रैंडमाइज्ड MAC एड्रेस का उपयोग करते हैं, जो MAB को पूरी तरह से तोड़ देता है, और MAC एड्रेस को सेकंडों में स्पूफ किया जा सकता है। आधुनिक नेटवर्क आर्केटेक्चर EAP-TLS का उपयोग करके 802.1X ऑथेंटिकेशन की मांग करता है। यह सुनिश्चित करता है कि प्रत्येक डिवाइस को नेटवर्क को छूने से पहले क्रिप्टोग्राफिक रूप से सत्यापित किया जाए। लेकिन चुनौती यह है: आप अपने हेल्पडेस्क को प्रभावित किए बिना हजारों अनमैनेज्ड डिवाइसेस में अद्वितीय क्लाइंट सर्टिफिकेट कैसे वितरित करते हैं? इसका उत्तर Simple Certificate Enrollment Protocol, या SCEP है। आइए आर्किटेक्चर से शुरुआत करें। SCEP एंटरप्राइज डिवाइस एनरोलमेंट के लिए उद्योग मानक है, जिसे RFC 8894 में परिभाषित किया गया है। यह 1999 से अस्तित्व में है, जिसे मूल रूप से VeriSign द्वारा बनाया गया था, और यह समय की कसौटी पर खरा उतरा है क्योंकि यह वास्तव में एक कठिन समस्या को सुरुचिपूर्ण ढंग से हल करता है। एक SCEP वर्कफ़्लो में, डिवाइस स्थानीय रूप से अपनी प्राइवेट और पब्लिक की (key) जोड़ी उत्पन्न करता है। यह एक Certificate Signing Request, या CSR बनाता है, और इसे Network Device Enrollment Service, जिसे NDES के रूप में जाना जाता है, के माध्यम से आपके Certificate Authority, या CA को भेजता है। CA अनुरोध को सत्यापित करता है और हस्ताक्षरित पब्लिक सर्टिफिकेट डिवाइस को वापस कर देता है। यहाँ महत्वपूर्ण सुरक्षा लाभ यह है कि प्राइवेट की कभी भी डिवाइस से बाहर नहीं जाती है। यह स्थानीय रूप से उत्पन्न होती है और डिवाइस के हार्डवेयर सिक्योर एन्क्लेव में संग्रहीत होती है। Windows लैपटॉप पर, वह Trusted Platform Module, या TPM है। iPhone पर, यह Secure Enclave है। प्राइवेट की कभी भी नेटवर्क पर प्रसारित नहीं होती है। यही बात SCEP को नेटवर्क ऑथेंटिकेशन के लिए PKCS जैसे विकल्पों की तुलना में कहीं अधिक बेहतर बनाती है, जहाँ CA केंद्रीय रूप से की (key) जोड़ी उत्पन्न करता है और इसे डिवाइस पर प्रसारित करता है। अब, आइए BYOD के बारे में बात करते हैं। परिचालन के दृष्टिकोण से यह वास्तव में दिलचस्प हो जाता है। आप चाहते हैं कि कर्मचारी आंतरिक टूल तक पहुँचने के लिए अपने व्यक्तिगत डिवाइसेस का उपयोग करने में सक्षम हों, लेकिन आप उन्हें अपने कॉर्पोरेट MDM में एनरोल करने के लिए मजबूर नहीं करना चाहते हैं। यह एक गोपनीयता की चिंता है, और कर्मचारियों द्वारा इसका कड़ा विरोध किया जाता है। इसका समाधान एक सेल्फ-सर्विस ऑनबोर्डिंग पोर्टल है। यह इस तरह काम करता है। उपयोगकर्ता अपने व्यक्तिगत डिवाइस को एक समर्पित प्रोविजनिंग SSID से कनेक्ट करता है। यह नेटवर्क एक वॉल्ड गार्डन (walled garden) है, जो ऑनबोर्डिंग पोर्टल और आपके पहचान प्रदाता के अलावा हर चीज़ तक पहुंच को प्रतिबंधित करता है। उपयोगकर्ता अपने कॉर्पोरेट क्रेडेंशियल्स का उपयोग करके प्रमाणित होता है, आमतौर पर Microsoft Entra ID, Okta, या Google Workspace के साथ SAML एकीकरण के माध्यम से। सफल ऑथेंटिकेशन पर, सिस्टम SCEP के माध्यम से एक अद्वितीय, डिवाइस-विशिष्ट क्लाइंट सर्टिफिकेट उत्पन्न करता है। डिवाइस पर एक कॉन्फ़िगरेशन प्रोफ़ाइल भेजी जाती है जिसमें सर्टिफिकेट, रूट CA सर्टिफिकेट और नेटवर्क सेटिंग्स होती हैं। इसके बाद डिवाइस स्वचालित रूप से EAP-TLS का उपयोग करके सुरक्षित कॉर्पोरेट SSID से कनेक्ट हो जाता है। यह उपयोगकर्ता के लिए निर्बाध और एंटरप्राइज के लिए सुरक्षित है। उन्हें सर्टिफिकेट या 802.1X के बारे में कुछ भी जानने की आवश्यकता नहीं है। वे बस एक बार लॉग इन करते हैं और कनेक्ट हो जाते हैं। अब, आइए कार्यान्वयन को विस्तार से समझते हैं। डिप्लॉयमेंट सीक्वेंस महत्वपूर्ण है, और इसे गलत करना विफलता का सबसे आम कारण है। चरण एक: विश्वसनीय रूट सर्टिफिकेट डिप्लॉय करें। इससे पहले कि कोई भी डिवाइस क्लाइंट सर्टिफिकेट का अनुरोध कर सके या आपके RADIUS सर्वर पर भरोसा कर सके, उसे जारी करने वाले Certificate Authority पर भरोसा करना होगा। अपने रूट CA सर्टिफिकेट को .cer फ़ाइल के रूप में एक्सपोर्ट करें और इसे अपने लक्षित डिवाइस समूहों में डिप्लॉय करें। यह चरण गैर-परक्राम्य है। इसके बिना, पूरी श्रृंखला विफल हो जाती है। चरण दो: SCEP सर्टिफिकेट प्रोफाइल कॉन्फ़िगर करें। यह डिवाइसेस को निर्देश देता है कि वे अपना क्लाइंट सर्टिफिकेट कैसे प्राप्त करें। आपको सब्जेक्ट नेम फॉर्मेट कॉन्फ़िगर करना होगा। यूजर-संचालित ऑथेंटिकेशन के लिए, मानक CN equals UserPrincipalName है। डिवाइस ऑथेंटिकेशन के लिए, CN equals Azure AD Device ID का उपयोग करें। की (key) के उपयोग को डिजिटल सिग्नेचर और की एनसिफरमेंट पर सेट करें। एक्सटेंडेड की यूसेज के तहत, OID 1.3.6.1.5.5.7.3.2 के साथ Client Authentication निर्दिष्ट करें। इस प्रोफाइल को चरण एक के विश्वसनीय रूट सर्टिफिकेट प्रोफाइल से लिंक करें। और अपने NDES सर्वर का बाहरी URL प्रदान करें। चरण तीन: 802.1X WiFi प्रोफाइल डिप्लॉय करें। यह सर्टिफिकेट को नेटवर्क SSID से जोड़ता है। नेटवर्क का नाम ठीक वैसे ही दर्ज करें जैसे यह आपके एक्सेस पॉइंट्स द्वारा प्रसारित किया जाता है। सुरक्षा प्रकार को WPA2-Enterprise या WPA3-Enterprise पर सेट करें। EAP प्रकार को EAP-TLS पर सेट करें। क्लाइंट ऑथेंटिकेशन सर्टिफिकेट के रूप में SCEP सर्टिफिकेट प्रोफाइल का चयन करें। और सर्वर सत्यापन के लिए विश्वसनीय रूट सर्टिफिकेट निर्दिष्ट करें। इस पूरी ब्रीफिंग से याद रखने वाली सबसे महत्वपूर्ण बात यह सीक्वेंस है। पहले ट्रस्ट, फिर सर्टिफिकेट, फिर WiFi। इसी क्रम में, हर बार। अब मैं आपको कुछ सर्वोत्तम प्रथाओं के बारे में बताता हूँ जो आपको प्रोडक्शन में होने वाली बड़ी परेशानियों से बचाएंगी। पहला, Azure AD Application Proxy के माध्यम से अपना NDES सर्वर प्रकाशित करें। NDES सर्वर इंटरनेट से सुलभ होना चाहिए ताकि रिमोट डिवाइसेस को साइट पर आने से पहले सर्टिफिकेट प्रोविजन करने की अनुमति मिल सके। लेकिन किसी आंतरिक सर्वर को सीधे इंटरनेट पर उजागर करना एक बड़ा सुरक्षा जोखिम है। Application Proxy आपको इनबाउंड फ़ायरवॉल पोर्ट खोले बिना सुरक्षित रिमोट एक्सेस प्रदान करता है। दूसरा, BYOD डिवाइसेस के लिए कम अवधि के सर्टिफिकेट लागू करें। तीन साल के लिए वैध सर्टिफिकेट के बजाय, 90 दिनों के लिए वैध सर्टिफिकेट जारी करें। जब सर्टिफिकेट समाप्त हो जाता है, तो उपयोगकर्ता को ऑनबोर्डिंग पोर्टल के माध्यम से फिर से प्रमाणित होना होगा। यह स्वाभाविक रूप से नेटवर्क से पुराने डिवाइसेस को हटा देता है। एक डिवाइस जिसका 90 दिनों से उपयोग नहीं किया गया है, वह बस हट जाता है। किसी मैन्युअल सफाई की आवश्यकता नहीं है। तीसरा, और यह बिल्कुल महत्वपूर्ण है, सख्त Certificate Revocation List चेकिंग लागू करने के लिए अपने RADIUS सर्वर को कॉन्फ़िगर करें। जब कोई कर्मचारी संगठन छोड़ता है, तो उनके Active Directory खाते को अक्षम करने से उनकी WiFi पहुंच तुरंत रद्द नहीं हो सकती है यदि उनका क्लाइंट सर्टिफिकेट वैध रहता है। आपके RADIUS सर्वर को पहुंच प्रदान करने से पहले CRL की जांच करनी चाहिए। सुनिश्चित करें कि आपके CRL Distribution Points अत्यधिक उपलब्ध हैं। यदि RADIUS सर्वर CRL तक नहीं पहुंच पाता है, तो सभी के लिए ऑथेंटिकेशन विफल हो जाता है। यह एक व्यापक आउटेज है। आइए अब कुछ सामान्य विफलता मोड और उनसे बचने के तरीकों पर नज़र डालें। सबसे आम समस्या WiFi प्रोफाइल का लागू न होना है। डिवाइस को विश्वसनीय रूट और SCEP सर्टिफिकेट प्राप्त होते हैं, लेकिन WiFi प्रोफाइल MDM कंसोल में Error के रूप में दिखाई देता है। दस में से नौ बार, यह ग्रुप टारगेटिंग बेमेल (mismatch) के कारण होता है। यदि SCEP प्रोफाइल किसी यूजर ग्रुप को सौंपा गया है, लेकिन WiFi प्रोफाइल किसी डिवाइस ग्रुप को सौंपा गया है, तो MDM निर्भरता को हल नहीं कर सकता है। अपने असाइनमेंट का ऑडिट करें। सुनिश्चित करें कि तीनों प्रोफाइल बिल्कुल एक ही ग्रुप को लक्षित करते हैं। दूसरी आम समस्या NDES 403 Forbidden त्रुटियां हैं। डिवाइसेस SCEP सर्टिफिकेट प्राप्त करने में विफल रहते हैं, और NDES IIS लॉग HTTP 403 त्रुटियां दिखाते हैं। यह आमतौर पर कनेक्टर सेवा खाते में सर्टिफिकेट टेम्पलेट पर आवश्यक अनुमतियों की कमी के कारण होता है, या फ़ायरवॉल SCEP द्वारा उपयोग किए जाने वाले विशिष्ट क्वेरी स्ट्रिंग मापदंडों को ब्लॉक कर रहा होता है। सत्यापित करें कि कनेक्टर खाते के पास CA टेम्पलेट पर Read और Enroll अनुमतियां हैं। अपने फ़ायरवॉल लॉग की जांच करके सुनिश्चित करें कि operation equals GetCACaps पैरामीटर वाले URL ब्लॉक नहीं किए जा रहे हैं। व्यावहारिक रूप से यह कैसे काम करता है, इसे समझाने के लिए मुझे आपको दो वास्तविक परिदृश्य देने दें। परिदृश्य एक: व्यक्तिगत स्मार्टफोन का उपयोग करके शेड्यूलिंग ऐप तक पहुँचने वाले 50 हाउसकीपिंग कर्मचारियों के साथ एक 200 कमरों वाला होटल। IT प्रबंधक कर्मचारियों की गोपनीयता का सम्मान करने के लिए पूर्ण MDM एनरोलमेंट से बचना चाहता है। इसका समाधान Microsoft Entra ID के साथ एकीकृत एक सेल्फ-सर्विस पोर्टल है। कर्मचारी प्रोविजनिंग SSID से कनेक्ट होते हैं, अपने Entra ID क्रेडेंशियल्स के साथ लॉग इन करते हैं, और एक SCEP प्रोफाइल डाउनलोड करते हैं। SCEP सर्वर सीधे डिवाइस पर 30-दिवसीय क्लाइंट सर्टिफिकेट जारी करता है। डिवाइस EAP-TLS का उपयोग करके Staff WiFi SSID से कनेक्ट होता है। RADIUS सर्वर इन डिवाइसेस को एक प्रतिबंधित VLAN में असाइन करता है जो केवल शेड्यूलिंग ऐप तक पहुंच की अनुमति देता है। जब कोई कर्मचारी इस्तीफा देता है, तो उनका Entra ID खाता अक्षम कर दिया जाता है, और RADIUS सर्वर तुरंत नेटवर्क पहुंच से इनकार कर देता है। परिदृश्य दो: कॉर्पोरेट-स्वामित्व वाले पॉइंट-ऑफ-सेल टैबलेट के लिए सुरक्षित WiFi डिप्लॉय करने वाली 500 स्टोर वाली एक राष्ट्रीय रिटेल श्रृंखला। नेटवर्क आर्किटेक्ट को यह सुनिश्चित करने की आवश्यकता है कि यदि कोई टैबलेट चोरी भी हो जाता है, तो क्रेडेंशियल्स को निकाला नहीं जा सकता है। इसका समाधान SCEP के माध्यम से सर्टिफिकेट डिप्लॉय करने वाला Microsoft Intune है। Intune विश्वसनीय रूट सर्टिफिकेट भेजता है, जिसके बाद एक SCEP प्रोफाइल आता है जो टैबलेट को अपने हार्डवेयर सिक्योर एन्क्लेव में अपनी प्राइवेट की उत्पन्न करने का निर्देश देता है। टैबलेट NDES सर्वर को एक CSR सबमिट करता है, क्लाइंट सर्टिफिकेट प्राप्त करता है, और EAP-TLS का उपयोग करके Retail POS SSID से कनेक्ट होता है। चूंकि प्राइवेट की स्थानीय रूप से उत्पन्न होती है और कभी प्रसारित नहीं होती है, इसलिए चोरी हुए टैबलेट के क्रेडेंशियल्स का उपयोग कहीं और नहीं किया जा सकता है। यह PCI-DSS अनुपालन आवश्यकताओं को पूरा करता है। अब, आइए बिजनेस केस के बारे में बात करते हैं। SCEP 802.1X सर्टिफिकेट डिप्लॉयमेंट पर संक्रमण सुरक्षा और संचालन में मापने योग्य रिटर्न प्रदान करता है। पासवर्ड-आधारित WiFi बड़ी संख्या में हेल्पडेस्क टिकट उत्पन्न करता है। पासवर्ड की समाप्ति, लॉकआउट, टाइपो। सर्टिफिकेट-आधारित ऑथेंटिकेशन उपयोगकर्ता के लिए अदृश्य है। डिवाइस स्वचालित रूप से कनेक्ट होते हैं। यह आमतौर पर WiFi से संबंधित हेल्पडेस्क वॉल्यूम को 70% तक कम कर देता है। यह परिचालन लागत में एक महत्वपूर्ण कमी है। EAP-TLS क्रेडेंशियल हार्वेस्टिंग और मैन-इन-द-मिडल हमलों के जोखिम को समाप्त करता है। यह रिटेल वातावरण में PCI-DSS और सभी क्षेत्रों में GDPR के अनुपालन के लिए महत्वपूर्ण है। डेटा उल्लंघन की लागत एक उचित PKI इन्फ्रास्ट्रक्चर को डिप्लॉय करने की लागत से कहीं अधिक है। और उन संगठनों के लिए जो पहले से ही Purple का Guest WiFi और एनालिटिक्स प्लेटफॉर्म चला रहे हैं, कर्मचारियों के BYOD डिवाइसेस तक सुरक्षित ऑनबोर्डिंग का विस्तार करना एक एकीकृत नेटवर्क प्रबंधन रणनीति प्रदान करता है। Purple का हार्डवेयर-अज्ञेयवादी क्लाउड ओवरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, और Fortinet के साथ एकीकृत होता है, इसलिए आप किसी एक हार्डवेयर विक्रेता से बंधे नहीं हैं। Purple 80,000 लाइव स्थानों पर काम करता है और उसने 2024 में 440 million लॉगिन संसाधित किए हैं, जिसके पास ISO 27001, GDPR, CCPA और Cyber Essentials प्रमाणपत्र हैं। मुझे आपके द्वारा लिए जाने वाले प्रमुख निर्णयों के त्वरित सारांश के साथ समाप्त करने दें। क्या आपको SCEP या PKCS का उपयोग करना चाहिए? WiFi ऑथेंटिकेशन के लिए SCEP का उपयोग करें। प्राइवेट की डिवाइस पर रहती है। PKCS का उपयोग केवल ईमेल एन्क्रिप्शन के लिए करें जहाँ की एस्क्रो (key escrow) की आवश्यकता होती है। सर्टिफिकेट कितने समय के लिए वैध होने चाहिए? BYOD के लिए 90 दिन। कॉर्पोरेट-प्रबंधित डिवाइसेस के लिए एक से दो वर्ष। क्या आपको अपने MDM में यूजर या डिवाइस टारगेटिंग का उपयोग करना चाहिए? उन कॉर्पोरेट डिवाइसेस के लिए डिवाइस टारगेटिंग का उपयोग करें जिन्हें उपयोगकर्ता लॉगिन से पहले कनेक्ट करने की आवश्यकता होती है। BYOD के लिए यूजर टारगेटिंग का उपयोग करें जहाँ सर्टिफिकेट व्यक्तिगत रूप से जुड़ा होना चाहिए। आप Android विखंडन (fragmentation) को कैसे संभालते हैं? जहाँ संभव हो, Passpoint का उपयोग करें, जिसे Hotspot 2.0 के रूप में भी जाना जाता है। यह Android निर्माताओं के बीच एक सुसंगत कनेक्शन अनुभव प्रदान करता है। और अंत में, सही करने के लिए सबसे महत्वपूर्ण बात क्या है? आपके RADIUS सर्वर पर CRL चेकिंग। इसके बिना, एक रद्द किया गया सर्टिफिकेट अभी भी नेटवर्क पहुंच प्रदान कर सकता है। यह आज की ब्रीफिंग का अंत है। यदि आप इनमें से किसी भी विषय पर गहराई से जाना चाहते हैं, तो एंटरप्राइज WiFi सुरक्षा और EAP-TLS सर्टिफिकेट ऑथेंटिकेशन पर Purple की तकनीकी गाइड Purple की वेबसाइट purple.ai पर उपलब्ध हैं। सुनने के लिए धन्यवाद।